A classic debate in Software Engineering is about whether investing effort into building high-quality software is worth it or not. In this article, we will go through the different aspects of this question and dive into the trade-offs.
Reviewing software quality
In a previous article [1], we have defined software quality as:
The quality of a system is the degree to which the system satisfies the stated and implied needs of its various stakeholders, and thus provides value. Those stakeholders’ needs (functionality, performance, security, maintainability, etc.) are precisely what is represented in the quality model, which categorizes the product quality into characteristics and sub-characteristics.
ISO/IEC 25010
The general quality/cost trade-off
In general terms, whenever you acquire a product or service; the cost increases as the quality improves. The more needs are satisfied, the better the quality, and equally more expensive.
Does software quality behave the same as other products?
Let’s say your requirements are for the software to be portable, maintainable, reliable, secure and performant, apart from the functional requirements. Provided you have built quality software, meaning has met all requirements; your software will be modular with low coupling and high cohesion, fault-tolerant, resilient, optimized code, etc.
Furthermore, when the Software Development team needs to build new features, the implementation cost will decrease, meaning less effort will be required to design, build, test and deploy new features. As a result, effort over the long run will either be stable or even improve.
Provided a fixed budget (or a fixed number of days of work); the following diagram shows 2 curves over time. The vertical axis is the number of features accumulated. In this representation, you can infer that the red ‘lower quality’ curve delivers more features at the beginning, however in the longer term, the blue ‘high quality’ curve delivers a lot more accumulated features over time. Consequently, the long-term benefits keep compounding over time.
High-quality software is cheaper and faster to produce
The higher cost at the beginning is hard to believe. In essence, we are making a promise that if we follow modern software engineering practices, which produce high-quality software, such as continuous delivery, test-driven development, testing automation, etc.; it will be cheaper and faster in the long run.
There is no trade-off between delivering software faster and high quality. Teams that score poorly on speed, they score poorly in quality. The opposite is also true, teams with high quality outputs, score high in speed of delivery as well.
Dave Farley – Continuous delivery [3]
The missing key ingredient in the graph is rework time. Poor quality software means finding why a bug is happening, what is the root cause, what was the requirement, etc. It is a long process and will inevitably slow us down.
As a result, we can conclude that it is not only the qualities of the software, also we need to take care of the software development process itself. High-quality software with poor software development practices will quickly degrade and go back to the mean in a short time.
