Functionality, Not Tools
"Functionality-based Programming". It is the direction we will be heading in software development, as we shed the low/no-code methodology. Software will be, and should be, built around the functionality it provides, not about how cool the hammer looks, or how easy the screwdriver is to use, or how any home DIY-er can now "build" their own home.
In my last newsletter, I talked about why low/no-code software is the wrong focus for software development. I want to mention again that I am not against the movement, and that I use those tools in some of my solutions. They are great tools for certain jobs! But as a way of programming as a whole, it is doomed for failure by its very nature. Which is ok and not a negative! It is a necessary step in the direction of where software needs to go.
Over the years that gap between the geeks and the business folks grew to the point where it took business analysts and technical business leaders to interpret and translate between the two groups.
Any PMs out there want to share their war stories??
The two groups are not good at working together -- each thinks they are right and have the best solution for any given problem, and fight vociferously to get the respect and solution they feel they deserve. They tend to undermine each other, avoid the PMs (who are trying to understand both sides and mediate the right solution), and often will make things happen without the other side's buy-in or approval.
The geeks always thought they were smarter, so they started to be asked to build good business solutions that people would use. Some CIO thought "we need software that does x" and throws down his 3-year plan for how the geeks are going to rally around it and make it the "flagship" product that solves all the financial woes. Hey, the CIO is not really eating at the C-Suite lunch table, so this one software package should change all that....and give her/him the respect they feel they deserve. Though there are notable winners who have achieved the goal in this, there are many thousand that don't, many softwares that die pre-launch, many revolving CIO doors with the next candidate SURE they can do what the predecessor could not.
Meanwhile, the business people continue to lament that they rely on geeks, since the geeks have the technical skills to make things happen. PMs, who usually answer to and are paid by the C-Suite, rarely have the pull in the geek world; they are seen as extensions of the business side of things, trying to coerce the technical side to do what the business side wants.
The gap between geeks and business is so huge that we are actually celebrating not working together! Geeks are happily making business software that people feel they have to work around, and now business people can build their own software without geeks! This low/no-code methodology is a natural progression of how software is built.
But its flaw of trying to give screwdrivers and hammers to business people will be its fatal flaw. It first requires a DIY-er to want to take it on, and that person needs to think like a geek. They have to think "screen and fields", "validations and actions", "buttons and dropdowns". They are told they can build anything they want! (Anything a geek thinks you will want to build) And once the easy-peasy screens with fields, buttons and logo are done, the business person will ask for more and guess what...you need code for that. You need to hire a geek to help you. You need someone else to build what you actually need.
The DIY-er, even a smart one, cannot build their own home. It takes learning how to build a home. It takes experience. You cannot give someone a shiny awesome hammer and some wood plus a blueprint and assume a single-family home will be built.
The next logical step in the software world will come soon after this. I am calling it, for today, "Functionality-based Software". The name doesn't matter, but the idea is that software needs to provide chunks of FUNCTIONALITY to be used by all business people, innovators, etc.
Recommended by LinkedIn
Think of a LEGO® set. For years, business people wanted an awesome spaceship. The geeks said that was stupid and made them two rockets since it was what they felt was needed to get the job done. All sides realized a box of 5000 pieces was a geeks playland.
So the no-code world sprung up out of a need to give the business people some power back. Geeks gave the business people great instruction booklets that show them how to build the components they need to build any (simple) spaceship they want! And they provided only the pieces they would need. And made it so any business person who wanted to build something could! Huzzah!
The geeks missed the point. As freeing as their idea was, it still missed the mark on what was needed. The business people still want a freaking awesome spaceship! The tools given to them allow them to build simple rocket ships. There are no instructions for the big awesome spaceship.
What if the geeks focused on functionality instead of tools? Start from the spaceship and work back. The spaceship needs a helm. It needs 4 engines. It needs 3 wheels for landing...no wait...100 wheels. It needs 3 levels. It needs shields. It needs to go fast. It needs communication with Earth. It needs to be out there for months at a time. Etc etc etc.
Dave takes 100 pieces from the box and builds an engine that rocks. Suzy takes 75 pieces from the box and makes tremendously strong shields. Other devs, like Yvonne, get into the box and build components too. Some parts are like Dave's and Suzy's, some devs focus on other parts, seeing the needs.
"Dave builds the best engines...let's get 4 of his that meet our specs. But we've got to use Suzy's shileds since hers are the lightest and most protective" See the difference in what the business side has to focus on? And if Dave's engines end up being not quite as good as Yvonne's, then they can swap them out!
Software is built based on functionality. Solutions are built on connecting software together, NOT on software itself. Solutions like a spaceship are built by taking components that happen to be software, and connecting them together.
Need email in your solution? Done. Need SMS? Done. Want a customer screen? Done. Doing invoicing? Done. Each part is a component that is rock solid, tested, secure. Built onto a swappable frame that the best minds have come up with. The blueprint is built on solid business ideas that revolve around FUNCTIONALITY.
Oh, it's coming. I'm here to help prime the pump. I envision ecosystems of components and builders and ideas. It really isn't that big a leap from where we are. It just takes glomming the LEGO® pieces into usable components that work on a swappable frame.
Couldn't agree more. I just wrote a very similar piece relating to breaking down SOC operations into smaller pieces: https://sprwlabs.com/blog/building-blocks Software really doesn't change regardless of where's it is being made...