You Are Either Over- or Under-Estimating the Importance of Software Quality
I saw a thread on Twitter this past weekend about a topic that developers just cannot get enough of: Software Quality.
If Nacho will forgive me, I’ll summarize his thread like this: if we built planes like we built software, they would be terrible. It immediately made me think of an exchange between GM and Microsoft, making a similar analogy between cars and software. Sadly, this was debunked. But, the underlying point still holds. Planes and cars are surely not perfect, but they seem pretty damn good compared to most software.
Is there some fundamental issue with software development that makes it worse? When someone says a programmer undermines the discipline of engineering by calling themselves an engineer, it does not bode well for the profession. And, you’d be hard-pressed to find anyone, let alone a programmer, that thinks software is good. What’s going on here?
I don’t know the answer to this. But, I do think that, like most analogies, there are important differences that make the comparison tricky when you starting looking closely. For starters, if you crash your plane, you can’t just restore it from a backup. You cannot upgrade to the latest version of your plane. You cannot just walk up to a plane, press a button, and make an exact copy. Software and physical things just aren’t the same. Analogies are very powerful, but they are also all flawed.
Humans understand physical things at a very fundamental level. We “build” software and “ship” it to customers. These are very useful metaphors. It is easier for us to map these actions to physical processes, because we live in the physical world. But, that is not what software is. I believe software is fundamentally different, and possibly unique.
One of the reasons software is so different is its constraints. The rules of software systems are defined by only other humans. A plane is constrained by aerodynamics, material properties, manufacturing processes and tolerances. But, there are so few fundamental constraints in software. In fact, sitting here, I’m struggling to think of any at all. Hardware, maybe. But the hardware’s behavior is defined by humans, and often completely hidden by yet more software.
My fear is that the relationship between quality and profitability for software doesn’t look anything like it does for physical things. There are an enormous number of examples of software that are very low-quality, but hugely profitable. The minimum acceptable quality is so much higher for physical things. A plane that fails sometimes will sell zero units. A piece of software that you have to restart once/twice a day? Mild inconvenience.
(Yes, I know there are applications where software failure is “unacceptable”. A government-funded space program is a classic example. Generally, I think comparisons between these and for-profit endeavors are problematic. I hope you agree, but I would be interested to hear if you do not.)
I believe software developers, as a rule, overestimate the importance of quality to their business. Do software companies/products fail in the market because of bugs? I’m sure they do, but I think it’s rare. In fact, I’ll wager one American dollar that there’s a strong correlation between valuation and snarky tweets.
On the other hand, I also believe managers grossly underestimate the importance of quality to their organization. Can companies succeed when built on old, crufty, bug-ridden code bases? Absolutely. Are the people paid to do it happy, productive, and doing great work? I’m not sure so. I’ll make another wager — there’s a strong correlation between turn-over and an organizations investment in quality.
The drive to produce high-quality software is a noble one. We, as an industry, should be trying to do better. If you are a programmer, you probably over-emphasize quality. If you are a manager, you probably under-invest in it.