The other day I heard someone use that well-worn phrase, “Quality is not negotiable.” They were talking about the reliability of the software their teams write, and were keen to stress that those teams shouldn’t be allowed to write buggy code.
I’ve written before about the negotiability (or not) of quality in software systems. The very brief summary of that article is that test-driven development and similar techniques are important to produce reliable systems, but regarding quality in the more general sense it is pragmatic to allow variation, even though its level is mostly a by-product of other things—usually process choices—rather than something we set directly.
Still, it got me thinking: when is it more and less acceptable to negotiate (or just compromise a bit) on quality, given that it’s something that has many dimensions?
Low level bugs bite us painfully. They are the kinds of things that are painfully evident to users of a system, and which tend to be difficult to ignore once we’re aware of them. Usability problems are more subtle, and while they are costly they’re the kind of thing that often warrant discussion and not an immediate “fix”.
So it occurred to me that the lower down the stack we go, the more consequential quality problems are. For example, below software quality issues are infrastructure quality issues. If our infrastructure is unreliable, perhaps leading to occasional service outages, then it doesn’t matter how good the code is sitting on top of that.
Each layer of our product or service relies on the layers below it. A problem in a lower layer has consequences for everything higher up the stack.
I wouldn’t argue that lower-level details can’t be negotiated (for example, it makes sense to consider our cloud provider carefully, and balance cost with other factors); and I wouldn’t argue that we shouldn’t worry over user experience. But the lower level needs to be more reliable more of the time. Because if we don’t get that right then the effort we put into the higher levels becomes much less relevant.