Software Delivery Speed Patterns
Sundar Rajan Muthuraj, Clean Coder - Full Stack
Principal Engineer | Clean Architecture | Mentor
Over the past 2 decades, I am fortunate to have worked on various products & projects that has given me the opportunity and exposure to experience different types of software delivery speed in the industry. In this article, I wanted to define, describe, discuss the whats, whys, why nots and consequences of 4 most popular patterns that I have personally lived with, while delivering software at speed.
What is a pattern?
In software industry, we all know that a design pattern is a general repeatable solution to a commonly occurring problem in software design.
Taking parallels, I want to define delivery pattern (in the context of speed) as - a general repeatable solution to a commonly occurring speed related problem in software delivery.
What is the problem with the software delivery speed?
Well, when it comes to speed of software delivery, the truth is - there is no one-size-fits-all. Unfortunately, the industry knows this intuitively but do not want to apply it contextually. Let me explain that a bit more.
We all know Agile, Scrum, Sprints, Kanban, Lean etc etc... and finally ending up in estimating the work (software delivery) using these processes by factoring in the time (implicitly - whether you like it or not).
And we all know from our schooling that - whenever there is time and distance (backlog) defined, inherently there is a speed that can be measured!
And that is the problem.
Speed (s) = Backlog Executed (d) / Time (t)
And why measuring speed is a problem? Because there is no one-size-fits-all, when it comes to software delivery speed.
Now that we know / acknowledge the problem, let's deep dive some known patterns and solutions to the speed problem.
Speed Patterns Identified
There are four software delivery speed patterns, in my opinion. And they are
Like I promised in the beginning, lets go through the whats, whys, why nots and consequences for these speed patterns.
Fast Speed Pattern
What
This is a pattern which is best suitable to get a deal with the customer. We are showing to the customer that their problem can be solved! Wonderful.
Why
At a prototype stage, time > quality
Why Not
Because, this pattern is only for experimentation and showing a proof of concept, and it is not meant to build a product!
Consequences
The more we continue to move ahead with this pattern, we will end up in Hasty Speed Pattern and/or Slow Speed Pattern.
Solution
Do not stay in this pattern for long time. Move to Consistent Speed Pattern sooner. When there is more prototype work left, then move to Hasty Speed Pattern.
Hasty Speed Pattern
What
This is a pattern which is not ideally suitable in any real world use cases, however, unfortunately most of the startups fall prey into this pattern. It is still applicable as an extension to previous pattern - Fast Speed Pattern, only when the intention is to do more prototypes on top, and not a product.
Why
Iteratively, we want to build the confidence with the customer
领英推荐
Why Not
Because, this pattern is only for experimentation and showing a proof of concept, and it is not meant to build a product!
Consequences
The more we continue to move ahead with this pattern, we will end up in Slow Speed Pattern.
Solution
Do not stay in this pattern for long time. Move to Consistent Speed Pattern.
Slow Speed Pattern
What
This is the pattern in the industry today, that most of the software projects suffering from. It means - I am NOT deterministically able to add changes, features to the product. Because, if I change something, something else breaks which I have no idea why. And hence, I am slowing down in speed exponentially!
Why
Fast Speed Pattern and/or Hasty Speed Pattern was used to build the product.
Why Not
This pattern is the direction towards a point of no return in the future. Never, ever we should be in this pattern.
Consequences
The more we continue to move ahead with this pattern, we will end up delivering software much more slower exponentially.
Solution
We can adopt solutions from Working effectively with Legacy Code to add tests or start over again with the understanding of the speed patterns.
Consistent Speed Pattern
What
This pattern in the industry is a bit rare and underestimated big time. It means - I am ABLE TO deterministically add changes, features to the product.
Why
In this pattern, the Unit Tests are treated as the first class citizens in the code, alongside with production code. And helps you build the product that can sustain the test of times to come!
Why Not
This pattern is not applicable for building quick prototypes. Because at a prototype stage, time > quality
Consequences
The more we continue to move ahead with this pattern, the more we will have stable product and thereby happy customers!
Solution
Write less code. Follow the signals given by your unit tests. A lot of time, we unintentionally write some lines of code that are not needed and that's where your unit test coverage yells at you to delete those lines of code from the product. End result is: Needed code, Fully tested, Consistent Pace!
Conclusion
The speed of delivery of software is purely dependent on the nature of the project and the people involved. The four patterns covered above ideally shows the possibilities that we can potentially have, and gives an option to pick one based on what stage we are into software development, to establish optimum speed! Recalling the original problem statement - there is no one-size-fits-all.
Happy coding and Happy delivering software consistently!