A popular discussion in software development projects is between spending time on enhancing the quality of the software vs focusing on developing more important features.
Over time, there were many cases when the developers have likely attempted to explain to the management why they should not skim on investing in quality, but have failed to persuade them. The result: instead of minimizing features from the next release, actually the quality investments such as unit tests, refactoring code and design documentation are reduced.
The pressure to deliver functionality is dominating the debates, forcing many developers to complain that they have no time to focus on the quality of architecture and code.
The trade-off between quality and cost
When you buy a new phone, you have 2 options: to choose a more expensive model with a faster processor, better screen and more memory, or, you can give up some of these features for a cheaper model.
We tend to have different values to quality, but what is generally valid is that higher quality usually costs more.
What does count as software quality?
Might be the user-interface, the reliability or the architecture. All these are important to highlight a crucial point: if I’m a customer or a user, I don’t appreciate some of the things we’d refer to as quality. Even though an user and a customer will notice defects, they can’t perceive the architecture of the software.
Which leads to the next question: since internal quality (the architecture) isn’t something that customers or users can see – does it matter?
Let’s take a simple example: Let’s imagine Lisa and I write a nutrition app. Both our apps have the same essential function. Also, they both have attractive and friendly user-interface and both have hardly any defects. The only difference is regarding the internal source code: Lisa’s code is neatly organized while mine is a true mess. Plus, the price: mine is $10 and hers $15. The user is not able to see the internal source (which doesn’t affect the way our apps are operating). In this case, is it justified to may more just for higher internal quality? At first glance, of course not!
The conclusion? It makes no sense to trade cost for internal quality. In fact, external software quality (such as UI and defects), is the one that worth the extra money.
Since this is the case, why should any software developer put the time and effort into improving the internal quality of their work?
Should internal quality be neglected?
Of course not!
Wondering why? Because one of the most important features of internal quality is the advantage of making it easier for the developer to figure out how the application works and how to add things.
If the software is nicely divided, the effort is reduced, because the developer doesn’t have to read all lines of code in order to solve the issues.
Additionally, better internal quality makes adding new features easier, quicker and cheaper.
Related to the example above, Lisa and I have the same application at the moment, but in the next period, Rebeca’s organized and high internal quality will allow her to add new features in a blink, while I will be stuck digging through the code to get just a single new feature out.
The result? The customers will give up my app, and get Lisa’s instead, even though the price is higher.
The impact of internal quality in the long run
Internal quality’s main function is to reduce the cost of future change. But writing good software involves some extra effort, which in the short term imposes some costs.
High internal quality will keep cruft to a minimum, allowing a team to add features with less effort, time, and cost. Keep in mind that even a great team can produce cruft. But by keeping internal quality high, the team will be able to keep the situation under control. Anyway, for better results make sure you choose the best team for your project!
Internal quality is very important for the software business, but it needs to be portrayed as something that the business clearly wants, rather than something it doesn’t quite comprehend.
Conclusion > High quality software is cheaper to produce! So, it is important to maintain high internal quality even on some “slower output” at project startup.