In Tradable Quality Hypothesis, Martin Fowler says “as soon as you frame internal quality as tradable, you’ve lost.” At the risk of being rode out on a rail, I argue that making quality non-negotiable lets engineers off the hook for understanding internal quality. Quality is always negotiable, and you should understand the benefits and costs of internal quality so you can negotiate and prioritize well.
Quality has gotten short shrift in most organizations. Software quality can dramatically affect future productivity. Since we often inappropriately sacrifice quality for features, it can sometimes make sense to stamp your foot and say “quality isn’t negotiable.”
However, understanding which software quality efforts actually matter requires us to think more deeply. How does software quality affect us? Most software quality problems—copy-paste code, non-standard formatting, bad encapsulation, poor use of modern language features (generics, iterators, etc.), simultaneously maintained code branches—degrade future engineer productivity. Other software quality problems—known bugs, inadequate test coverage—degrade software value.
With a subtle understanding of quality, you can answer daily questions in context. For example, should you refactor a long-untouched body of code for future productivity? Sometimes you shouldn’t. But if fear of touching that code holds back new functionality, maybe you should. The Tomcat 7 committers just refactored a lot of long-untouched code, with likely productivity improvements going forward (and a whole bunch of bugs fixed). [see Mark Thomas: Introducing Tomcat 7 at 39:30]
Unless we make engineers defend their quality efforts, they fail to thoughtfully prioritize quality improvement efforts. Should they create unit tests or integration tests first? Most engineers can’t give you a thoughtful answer to this question. But they are going to do something first, and that something might be a lot less valuable than the other thing. I’ve seen poorly conceived quality efforts squander millions of dollars.
That’s why “quality is non-negotiable” articles always fall flat with me. They punt the tough questions. They seem well-suited for the “I never think about the value-side” engineering people to deal with “I never think about the effort-side” product people who keep making one-sided demands.
I like using Net Present Value to think about the cost-savings of quality improvement and the value of features. It helps me prioritize and compare options. Engineers have to make decisions about quality every day. They should hone their decision-making skills, and clichés are not likely to help.
