Quality vs Speed? I Don’t Think So!

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:

With greater capability, we can go faster at 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.

Posted on:

Written by: Ron Jeffries

Categorization: Articles

7 Responses to “Quality vs Speed? I Don’t Think So!”

Horia Dragomir

April 30, 2010

5:21 am

permalink

Yes! Thank you!

Still, you said nothing about the third part of the software triangle: money. Or compensation, to generalize.

The rule is that there needs to be a balance. If two points are high( like short time and good quality ) the third point must also be high( more compensation ).
When working for free, this is automatically satisfied because the compensation you really get is how you feel about the job — do a good job fast and you feel great!

When we bring this into the business realm, though, it’s no longer only about developers shipping out a great product. It’s also about compensation.

PS: I love the design of this site!

Ron Jeffries

April 30, 2010

5:56 am

permalink

Andre: Slacking: the evasion of work or duty.

Horia: I do not agree that compensation is the third leg of time and quality. Monetary compensation may be important, just as product revenue may be important. But I would not work with someone who told me he would do better work only if I paid him more.

Horia Dragomir

April 30, 2010

6:32 am

permalink

Ron Jeffries, right you are. I specified money before saying that I really mean compensation so that the note would be easier to digest.

Compensation can take many forms. Most commonly, it’s money. It can also be self-esteem, pride, recognition, what have you.

In other words, your motivation includes your desire to be compensated. No matter what that compensation might be.

In this sense, compensation is the third leg.

Ron Jeffries

April 30, 2010

8:13 am

permalink

People have many and complex needs and goals. None of these, it seems to me, interacts interestingly with the quality / time tradeoff. Given constant motivations, the quality/time equation will remain the same.

Horia Dragomir

April 30, 2010

8:50 am

permalink

Ron Jeffries, what happens, then, if you take the motivation away? In terms of quality/time, I mean.

My original point, though: if you don’t provide compensation, you cannot expect the best quality in the shortest of times. Excuse my digression, though.

I do think this is a great explanation on the whole quality vs. time issue. There’s been talk about this lately, and yours is the best article I’ve read so far.

Ron Jeffries

April 30, 2010

9:07 am

permalink

If people aren’t motivated, things won’t go as well. The Q/T tradeoff will still work. I’m not sure this is the best place for a conversation though, and I think I’ll let this be the last comment for now …

Recent Articles

Emergent Design

Martin Alaimo asked about the Manifesto Principle "The best architectures, requirements, and designs emerge from self-organizing teams."

XProgNew – Pivot?

Experience with Sinatra, and some thinking, cause us to look at a shift in approach. Martin Fowler was probably right.

Codea Calculator

Based on a simple example on the codea.io forums, I decided to write an article showing all the stuff I might do on a production calculator project. Wow.