[Update on February 7, 2009: I need to rewrite this article, and I will, so if it has confused you, don’t worry. I will fix that soon.]

I haven’t yet learned how to measure it, but I believe I have identified a kind of Law of Software Development that I call the Law of the Quality/Speed Barrier. This law states the following.

For any project we can find a quality level below which one must trade off quality and speed and above which one derives more speed from better quality.

Now I admit that this definition suffers from a lack of precision, so let me explain what I mean. Please hold your cards and letters about the pointlessness of the word
quality.

We can measure quality by looking at any useful measure of the general software development community considers to represent quality: defect rate in time, defect density, defect totals, weight defect totals by severity or urgency, marginal cost of a feature, average cost to fix a defect, average cost to assess impact of a proposed change. I don’t mind which you choose, because for the purposes of the Law of the Quality/Speed Barrier, any will do.

We can measure speed by looking at the usual measure of speed: effort required to design and correctly implement an average-difficulty feature, team velocity, team velocity trends over time, cost to deliver an average-difficulty feature. Again, choose the one you like, since any one will do.

However you wish to measure quality and speed, if you have high enough quality, then more quality helps you attain more speed; and if you have low enough quality, then you have to sacrifice quality for more speed and you have to sacrifice speed for more quality. I have not studied hundreds of projects to defend my position; however, I have worked to varying degrees on dozens of projects, and I believe the law has held in all those cases.

You might have observed this in your own project, largely as a general feeling that you might find difficult to substantiate with data, but that nonetheless your every observation seems to confirm.

What I find most vexing about this law concerns the conclusion that in order to move above the Quality/Speed Barrier, one must sacrifice speed in the interim. My consulting practice includes helping organizations accurately decide when they should start investing more heavily in the kind of change program that would help them increase quality, reach, then eventually surpass, the Barrier. For most, a simple awareness of the Barrier makes it easier to know whether to invest in trying to cross it. In most cases, teams find themselves above the Barrier because they made an agreement to start above the Barrier and not allow themselves to fall below it. It appears much easier to maintain your position above the Barrier if you’ve started there, just as it appears easiest to maintain your position below the Barrier if ever you’ve let yourself fall below it, whether you’ve started below it or not.

I encourage you to gather some informal feedback from your team about this question. Do you believe you operate above or below the Barrier? How do you know? Do you believe you have started above the Barrier and fallen below it? What have you seen or heard that makes you believe that? Most importantly, if you find yourself below the Barrier, what can you measure or detect that would help you estimate the return on a potential investment in training, changes in work habits and changes in work systems that would help you climb over the Barrier? How would you know you’ve succeeded?

As always, the questions matter more than the answers.