A common debate in software development projects is between spending time on improving the quality of the software versus concentrating on releasing more valuable features. Usually the pressure to deliver functionality dominates the discussion, leading many developers to complain that they don’t have time to work on architecture and code quality.
Betteridge’s Law of headlines is an adage that says any article with a headline or title that ends in a question mark can be summarized by “no”. Those that know me would not doubt my desire to subvert such a law. But this article goes further than that – it subverts the question itself. The question assumes the common trade-off between quality and cost. With this article I’ll explain that this trade-off does not apply to software – that high quality software is actually cheaper to produce.
Although most of my writing is aimed at professional software developers, for this article I’m not going to assume any knowledge of the mechanics of software development. My hope is that this is an article that can be valuable to anyone involved with thinking about software efforts, particularly those, such as business leaders, that act as customers of software development teams.
We are used to a trade-off between quality and cost
As I mentioned in the opening, we are all used to a trade-off between quality and cost. When I replace my smart phone, I can choose a more expensive model with faster processor, better screen, and more memory. Or I can give up some of those qualities to pay less money. It’s not an absolute rule, sometimes we can get bargains where a high quality good is cheaper. More often we have different values to quality – some people don’t really notice how one screen is nicer than another. But the assumption is true most of the time, higher quality usually costs more.
Software quality means many things
If I’m going to talk about quality for software, I need to explain what that is. Here lies the first complication – there are many things that can count as quality for software:
I can consider the user-interface: does it easily lead me through the tasks I need to do, making me more efficient and removing frustrations?
I can consider its reliability: does it contain defects that cause errors and frustration?
Another aspect is its architecture: is the source code divided into clear modules, so that programmers can easily find and understand which bit of the code they need to work on this week?
These three examples of quality are not an exhaustive list, but they are enough to illustrate an important point:
If I’m a customer, or user, of the software, I don’t appreciate some of the things we’d refer to as quality
A user can tell if the user-interface is good.
An executive can tell if the software is making her staff more efficient at their work.
Users and customers will notice defects, particularly should they corrupt data or render the system inoperative for a while. But customers and users cannot perceive the architecture of the software.
I thus divide software quality attributes into:
external (such as the UI and defects)
and internal (architecture).
The distinction is that users and customers can see what makes a software product have high external quality, but cannot tell the difference between higher or lower internal quality.
At first glance, internal quality does not matter to customers
Since internal quality isn’t something that customers or users can see – does it matter? Let’s imagine Rebecca and I write an application to track and predict flight delays. Both our applications do the same essential function, both have equally elegant user interfaces, and both have hardly any defects. The only difference is that her internal source code is neatly organized, while mine is a tangled mess. There is one other difference: I sell mine for $6 and she sells hers for $10.
Since a customer never sees this source code, and it doesn’t affect the operation of the app, why would anyone pay an extra $4 for Rebecca’s software? Put more generally this should mean that it isn’t worth paying more money for higher internal quality.
Another way I put this is that it makes sense to trade cost for external quality but it makes no sense to trade cost for internal quality. A user can judge whether they want to pay more to get a better user interface, since they can assess whether the user interface is sufficiently nicer to be worth the extra money. But a user can’t see the internal modular structure of the software, let alone judge that it’s better. Why pay more for something that has no effect? Since that’s the case – why should any software developer put their time and effort into improving the internal quality of their work?
Internal quality makes it easier to enhance software
So why is it that software developers make an issue out of internal quality? Programmers spend most of their time modifying code. Even in a new system, almost all programming is done in the context of an existing code base. When I want to add a new feature to the software, my first task is to figure out how this feature fits into the flow of the existing application. I then need to change that flow to let my feature fit in. I often need to use data that’s already in the application, so I need to understand what the data represents, how it relates to the data around it, and what data I may need to add for my new feature.
All of this is about me understanding the existing code. But it’s very easy for software to be hard to understand. Logic can get tangled, the data can be hard to follow, the names used to refer to things may have made sense to Tony six months ago, but are as mysterious to me as his reasons for leaving the company. All of these are forms of what developers refer to as cruft – the difference between the current code and how it would ideally be.
