The Performance paradox and maturity
Business wants feature, Engineer wants performance. Arguing for hours, but no one wins. They decide to flip a coin.
How to balance the demands of business and engineering in software development, each one has their correctness. How do we ensure that we deliver value to customers without compromising the quality of our code? How do we avoid technical debt and performance bottlenecks?
Balance. The most powerful controller
Velocity, Adaptability, Performance
Firstly, we will go through the term of words above
Velocity: how quickly to add a new feature to respond quickly to market changes, customer feedback, and competitive pressure.
Adaptability: how well the system can change to new requirements without breaking or requiring extensive refactoring.
Performance: how the your system handle increasing amounts of data, users, or requests without degrading the user experience or consuming excessive resources.
So here is how I image the relationship between three elements, in the image above. velocity, adaptability, and performance are interconnected elements in software development. There will always be trade-off when moving the red point to any corner or edges
Back to the foreword: Balance
As my view, the art of balance in this case is Timing. Answering the when question? When should we need velocity, when adaptability or performance?
The answer is: depends on the maturity of our software project. In general, we can think of three stages: prototype, product and platform
Prototype, product and platform
Prototype is the stage where we are exploring an idea or a problem and trying to find a viable solution. In this stage, we should focus on release velocity and code adaptability. We want to deliver a working prototype as fast as possible and get feedback from potential customers or users. We also want to make our code easy to change and experiment with different approaches. Performance in scale is not a priority in this stage, unless it is a core requirement of our solution.
Product is the stage where we have validated our solution and we are ready to launch it to a wider audience. In this stage, we should still focus on release velocity and code adaptability, but we should also start paying attention to performance in scale. We want to deliver new features and updates that add value to our product and delight our customers. We also want to make sure that our code can handle the expected load and growth of our product. Performance in scale is not a critical issue in this stage, unless it affects the user experience or the cost of running our product.
Platform is the stage where we have established our product as a market leader and we are serving a large and diverse customer base. In this stage, we should balance release velocity, code adaptability, and performance in scale. We want to deliver new features and updates that keep our product competitive and innovative. We also want to make sure that our code can support the complex and evolving needs of our customers. Performance in scale is a key factor in this stage, as it can make or break our product.
Yet, now you got the term, relation, methodology, back again to the real-world, how to apply this triangle?
Real-world approach
Dream big, start small
With a project, you got the big dream, think about how they can solve the customer pain points, ideas are just keep turning inside your head. True, that how every time we receive a project, Big Dream.
The painful truth is we can afford big things, the more looking to our dream, the more chaos feeling gain. The solution is: breaking it down, write down all of ideas, sketching it on a big map. Now we need to connecting all of our ideas, prioritize needs and then turning to a Roadmap
And in each stage of the roadmap is a cycle of development: Prototype → Product → Platform.
Final final 1
To sum up, we have explored the performance paradox and how it can be resolved by balancing the three dimensions of performance, velocity and adaptability. We have also proposed a development cycle that guides us to focus on the right dimension at the right time. This way, we can achieve optimal results and avoid trade-offs.
Problem solved?
Does this mean we have to stop the debate between engineers and business people? Of course not, the aim of this is to exchange our views with each other, not to end the conflict. What if the conflict persists? That's okay, because it creates balance and drives progress.
One of the biggest dilemmas we face is figuring out what stage we are in: Prototype, Product, or Platform? t's not easy to tell, because it depends on many factors and assumptions. This is an approximation. This is art.
