Cut quality to go faster? It could happen. There's more to the story, however.
Over the past months, some big-name Agile spokesmodels have spoken out in favor of cutting quality to go faster. This gives me concern. One of the most recent of these articles is also one of the best. Please check out Joshua Kerievsky on Sufficient Design.
I’m concerned about these articles, because they are describing risky decisions, made by experts, in terms that may too easily be misunderstood.
Time to Market is Important
Agile is all about early and continuous shipment of working software. So we cannot accept too much delay. We need to go as fast as we reasonably can.
We All Trade Off Quality and Time, Every Day
No one ships perfection: we’re not that good. What can we really say, with certainty, about reducing quality and its impact on shipping?
When Quality is Too Low -- We'll Never Ship
When our code quality gets low enough, we put in more defects. With enough defects, we can never ship the product, even if it is just a prototype for testing.
Therefore code quality needs to be above some unknown lower limit, or we’ll not ship on time.
When Quality is Too High -- We'll Never Ship
If we spend the next few years trying to decide on a variable name, we cannot ship the product for a few years. If we spend the next few weeks trying to generalize some code that works now, we will defer shipping for a few weeks.
Therefore code quality needs to be below some unknown upper limit, or we’ll not ship on time.
Stuck in the Middle With You
Between the clowns who can’t code on the left of me, and the jokers who can’t stop polishing on the right, I’m stuck here in the middle with you. What can we say about the middle?
I think of the possibilities being like this picture:
If we set quality too low, we never ship. If we set quality too high, we never ship. Somewhere in the middle, we feel, there may be an area where we can dial down the quality just a bit, and go faster.
Most everyone accepts that when we work below some quality optimum, we will slow down over the longer term. It’s also clear that sometimes we can slack a bit, and make it up. If we don’t have that extra hour to refactor a few methods, we can ship today, then refactor tomorrow, and ship again. We believe that we’ll wind up in the same high-quality place, just with an extra ship point before the hour of refactoring. That ship point could mean the difference between making an important deadline and letting someone down hard.
The Effect of Capability
Here’s another version of the picture, this time suggesting that the better we are, the faster we can go with high quality:
The green area shows the results if we can code at high quality, but rapidly. If we could do that, we could go faster than we can by coding at lower quality!
Is it possible that if we keep our focus on longer term sustainability, we can still go just as fast in the short term? I believe that it is possible, and that we already have credible evidence that it is possible.
Most of us believe that over the longer term, speed is maximized by operating at a high, but not stupidly high, level of quality. The question is, what is “longer term”?
Longer Term May Be Shorter Than You Think
When Chet and I are programming, we often make the decision not to clean something up during our arduous two-hour work day. Sometimes–of course quite rarely–we may actually make a design mistake or not notice an opportunity for improvement.
We always notice within a few days that the code seems to be fighting back. The poor design decisions of today always visit us within a few days: quite often we notice it the very next day.
The better we get, the more we practice, the faster we go with quality. For anything short of a couple of days, for us, slacking below our normal level of quality slows us down immediately. Slacking slows us down immediately!
It comes down to this:
If slacking on quality makes you go faster, it always comes at the cost of longer term quality.
Turning that around, if we were better than we are, we could go faster without cutting quality. We need to improve. Today may not be the day to make that improvement: Today we may really need speed more than we need quality. But the handwriting is on the wall:
If slacking on quality makes us go faster, it is clear evidence that there is room to improve our ability to deliver quality rapidly.