When developing and designing systems, it’s of utmost importance to understand the types of patterns software engineers follows to deliver their product. Whether the software being delivered is as simple as a new command line or something as large as an operating system.
Throughout my journey in the tech industry, I’ve observed how organizations shift their software delivery and productization patterns depending on the level of experience and the criticality of the product being delivered. I’ve come up with three very predominant patterns that exist in part or in full in every single software development team out there.
Let’s discuss those patterns in the following sections.

Chaos Pattern

This pattern here is the most popular one. Usually in certain organizations a new product will be proposed, and several “experienced” engineers will be hired to deliver that proposed “ground-breaking” product. Because of the competitive nature of the industry, some engineers will cut corners to get a product out the door violating every engineering principle they’ve ever learned to prove that they are “capable” of getting the job done.
This pattern usually comes in an environment that’s struggling for its survival and is trying to prove its existence and relevance. Engineers working in this environment find themselves in a situation where the investors and funders of the project don’t have much technical experience, ergo they don’t understand why adding a simple “button” for instance on a web page requires “all this testing” and “designing” to “make it happen”.
On the outside, the product gets developed, deployed, and demoed. Everyone is happy, everyone goes home. Except for the engineers. The engineers know that what they’ve created is a time bomb that’s about to cause all kinds of issues at the first glance of a new feature ask or a seemingly simple defect that seeks resolution.
Some so-called engineers would take their “rewards” and “promotions” and run as far away as they could from the “crime scene” to go on to pursue another chaos to make. The ones that take the fall for that chaos are juniors and interns who are already suffering from the imposter syndrome, so they’ll beat themselves up for not being able to even understand, let go fix the chaos instead of questioning the “legends” who created that very same chaotic system.
Chaotic systems built as prototypes then deployed and adopted as final products have massive negative impact on the business, the engineers and the product itself. A system built with no engineering standards costs ten times more to maintain, it bleeds the business to death to keep it running. It also impacts the engineers maintaining it physically, mentally and spiritually to the point where attrition becomes a serious problem and hiring talented engineers becomes a true challenge let go keeping them around.

But furthermore, chaotic systems parallelize the product itself. It makes it hard for the product to seamlessly grow and evolve. And it renders the user experience to become almost impossible the more features are developed, and performances are needed to be optimized.
As soon I stat describing the symptoms of a chaotic systems, I could see the surprised look into engineers’ eyes as if I’m telling them their fortune. They start asking me the very same universal question – what should I do? Should I run away? Should I fix it? How do I fix it? Management says: “if it works don’t fix it” and several other similar notions.
The answer to this question is simpler than some may think. Here’s how to fix this pattern:
Keep the business running – don’t add any more features to the chaos no matter how temporarily sad your business and stakeholders may seem.
Start rewriting the chaos – usually architectural patterns such as microservices are very helpful to keep new features coming built in the new components while still being connected to the chaos.
React to incidents at highest priority.
There are situations where systems live sites are occurring so often that a feature crew has to be formed to keep their minds away from the chaos while they modernize the system while a maintenance crew would handle keeping the chaos running for a short while.
As an engineering leader I usually alternate between feature and maintenance (and business) crews to keep everyone connected and fairly given the same shot at building features while refueling their passion by looking at how chaotic the legacy system may be.
The chaos pattern is the most common, but it’s not the only one. Some teams build proper systems from day zero. But they fall into a different trap that makes them subject to unnecessary criticism by the leaders of chaos – let’s talk about the second patten here.

Vertical Pattern

The vertical pattern engineers are good engineers. They work harder than anyone to ensure the new system is test-driven with telemetry and observability in place.
Vertical pattern engineers build their systems blade by blade. They invest 6 months or more building the infrastructure of their system. Then another 12 months building the business logic layers in an optimum cutting-edge manner.
And then after a year or two they start thinking about exposing their system to the outside world. By that time – some of the engineers drop off the project due to the lack of impact. It’s quite hard for some to wait 24 months or more to see their product come to light.
Within that very long period of infrastructure, integration, and business development the business itself might go under for their inability to hit the market fast enough. They run out of money and usually a competitor hires a bunch of chaos engineers to hit the market faster.
The worst-case scenario is a project that is being properly built with engineering standards that gets taken over by the leaders of chaos due to the business impatience to wait for a proper product to come out to the light.
This very scenario is the reason why the software industry today doesn’t have or respects any standardization. The industry is run by individuals or corporates with massive funds and no understanding of engineering whatsoever. They make the decisions based on the outcome (which is not wrong), but their vision doesn’t give regards or have any visibility for the quality of the process that led to that very outcome.

Vertical delivery engineers have the best intentions at heart, and best patterns and practices in minds. But their strategy is killing their potential to grow and evolve and continue to develop standardized systems in the software market.
I’ve witnessed some of the best engineers drop all their principles and standards and turn into chaos engineers because “that’s how the market works” or “I know it’s wrong, but we’ll go back and fix it”.
But the solution isn’t to turn into a chaos engineer. The solution isn’t to give in and let go of one’s principles and engineering standards. The solution is a lot easier and simpler than that.
After years and years of trial and error in the industry I’ve finally come to the conclusion that the best software delivery pattern out there is the horizontal pattern. A pattern that puts chaos engineers to shame and lifts up the vertical strategy engineers to a new level of success, happiness and prosperity.
Let’s talk about the horizontal pattern here.

Horizontal Pattern

Engineers who develop components of any system follow the very same principles and standards that the vertical engineers follow. But somehow Horizontal delivery engineers hit the market faster than both the chaos engineers AND the vertical delivery engineers with a high-quality product and maintainability from heaven.
How do they do that?
Horizontal engineers are developing against features and scenarios not technical components. They’ll ask the question, what components do I need to have today to delivery a user registration workflow? More often than ever they end up building components horizontally across the board from one realm to another.
For instance, they will develop one single component for database integration, then they hop off to test-driving logical components then integration the exposure layers with these very same logical components.

Horizontal software delivery when standardized can bring results, demos, and prototypes from the very first sprint in any software development team. Regardless how junior the team may be. Because clean software doesn’t need a “genius” or a “legend” to drive it. It should be simple by default and easy to understand and evolve by design.
Engineers who follow the horizontal delivery and standardized pattern are the true leaders of the tech industry. They know how to adapt and evolve their systems and mindsets with a forever changing industry while still always delivering the highest quality of software. These engineers are also the great promise of evolution for humanity. Because the very systems they build are the ones that is posed to inherit the earth and push the wheel of innovation forward. They bring happiness and prosperity wherever they go – they lift everyone up and shake off the rut of legacy chaotic systems off entire organizations.
The horizontal software delivery pattern is the path forward to hit the market soon – keep your investors and business stakeholders happy while engineering teams are evolving, growing and thriving as they maximize their experiences in delivery the best software systems ever built in the history of man.
Horizontal systems delivery is our way forward towards the survival, evolution of fulfillment of mankind. As technology becomes more and more involved in our daily lives we have to do our very best to ensure these very systems don’t destroy us, devolve us and diminish our very spirits – through and through from the moment these systems are being designed, developed to the moment they get deployed and distributed.