Abolish Unique Precious Snowflakes
Software professionals (software architects, designers, engineers, developers) are phenomenally good at creating bloat. Give any of those professionals a challenge, a problem, and watch them go away and then later on come back with bloated ‘solution’. It is extremely unlikely (verging on literally impossible) to see software professionals produce something lean, something not incredibly bloated.
We gotta ask ourselves a question: why is that? What is it in the discipline of software engineering/development that is so prone to producing bloat?
I think the answer lies in the ingrained perception that software code is a unique precious snowflake that has been lovingly crafted by some incredibly smart people. Of course, such carefully crafted precious snowflake commands a very high retail price.
That arrangement is good for creators of this bloat, but is bad for the paying customers. It is also bad for poor people who are then saddled with maintaining the steaming pile of bloat. It is therefore high time we break the vicious cycle and call a spade a spade. In other words, time to face the fact that there are no unique precious snowflakes in the world of software development. Ergo, no amount of hand crafted code should ever command high price tags.
Real World Analogy
It may help if we illustrate the current anomaly that is plaguing the world of software with an analogy from the real world. Suppose we teach someone how to build a house using bricks. Those bricks are standardized, uniform in size, perfect for building a sturdy house. So everything seems perfectly fine.
Suppose now we call these newly minted house building experts and ask them to build a bigger house. Are we expecting them to go back to the drawing board and design and build bigger bricks? No. We expect them to understand that to build a bigger house all they need is more of the same. More bricks, that’s all!
But for some reason in the world of software development, that’s not how things work. Whenever we ask any software development team to build a larger system, the first thing they’ll do is go off into a deep dive creating much larger building blocks. Hence bloat!
Why do we say that’s bloat? Because working with and maintaining bigger, more complex building blocks is a chore prone to all kinds of errors. Software professionals don’t seem able to work with the more of the same principle. They’ve been trained, from the get go, to only focus on building larger, more complex unique precious snowflakes.
How To Avoid Bloat?
In software, bloat seems inevitable. After all, that’s how software professionals have been trained, and that’s how many software vendors are making their fortunes. Software bloat seems very lucrative for software professionals.
In order to avoid this expensive and detrimental bloat, we need to stop appreciating unique precious snowflakes. So even if we were to agree on the undesirability of celebrating precious snowflakes, it still isn’t clear how would one do software development without this pervasive, ubiquitous bloat?
Here is the present situation: our world is a complex, complicated place. Hence our business objectives cannot help but also be complex. Currently, in order to model our business objectives and map them to software constructs, we always use complex structures. After all, mapping conceptual solution onto a complex real world system requires equal degree of complexity, no?
While the above is correct, it is how we go about this mapping of the complex concepts onto a complex real world situation that is of paramount importance. It’s similar to how we go about building a bigger house — instead of creating more complex building blocks, we can opt to go with more of the same principle. The important epiphany in software development comes at the moment when we realize that we can meet complex objectives by utilizing a large number of small simple steps.
Each small simple step is not a unique, precious snowflake (does not require carefully crafted code). Therefore, it’s not a bloat. The only smarts that a system comprising of a large number of small simple steps has is in the arrangement of those steps. To change the mapping of a complex objective, we don’t change the building blocks (i.e. any of those small simple steps). We only change the arrangement of those steps. No need to ever touch the originally implemented software code.
Using a more technical jargon, we can say that simple software components (the building ‘bricks’) need to be arranged into more or less complex networks. If the execution of a software program needs to be changed, we don’t modify the building bricks (the components, meaning we don’t touch the source code); we change the layout of the network that is comprised of those immutable components.
How Does The Network Execute The Program?
Unlike in the antiquated world of sequential programming, the network does not rely on a localized execution of the program. Instead, the network relies on two fundamental concepts:
- Addresses
- Messages
In the network-centric computing, messages are being pushed from address to another address. The progression of messages through the network is the actual execution of the program. And since the fundamental building blocks (bricks, or components) are not unique precious snowflakes (are not bloated), the only smarts needed for correct execution is found in the layout of the network. And as we’ve mentioned, to modify the execution of the program, we only modify the layout of the network. We never modify the simple building blocks of the network.
In this arrangement, the message is the application!
Conclusion
The time has finally come for software development professionals to abandon the obsession with unique precious snowflakes (i.e. software source code) and to embrace the standardized approach to building systems. Drawing from some examples form the real world engineering, we saw how desirable it is to avoid bloat at all costs.
The next thing one needs to do after reaching that epiphany is figure out how to go about avoiding that bloat. It is recommended to abandon the obsession with programming code, and instead focus on the skills needed to cleverly design complex networks. Those networks consist of ultra simple components that know how to keep pushing messages via the addressing system. That way, the risk of component bloat (the bloat creeping into the source code) gets completely mitigated.
