Excellent Post! very well put and crystal clear.

“Product buyers, and employers, want the best they can get for their money, not the worst.” “For their money” is the lynch pin of the argument and where it fails in reality.

“Lower quality makes you go slower” is true only if you include the user as the “you” in that sentence. Successful software companies are willing to trade quality for speed if the speed impact is to the customer and not to them. Many users are willing to restart their software, use a ten step process where one would do or suffer with a little wait, if there life is somewhat better than before. Great quality impact is spread across many users who are willing to suffer through the lack of quality.

One phenomenon that I have seen, not only in software but in many service oriented industries, is that the customer often does not know what they want. Does the customer want a great hamburger? Then why aren’t the finest restaurants making the finest quality hamburgers crowded with customers and why don’t those businesses have chains all over the world and sell billions of hamburgers? Because customers are willing to sacrifice quality for time and convenience.

I’ve been trying to tackle some of questions with my current project…I posted my thoughts in more detail over at http://geekswithblogs.net/Optikal/archive/2009/02/09/129299.aspx

In your listing of the two ways (or was it three?) in which you found the EITHER/OR thinking to be troublesome, I noticed that you didn’t include the one that has always bothered me the most.

Whenever a project manager, customer or other stake-holder, in the grip of fear at the thought of a project shipping late, would insist that a development team “cut quality in the interests of meeting a date”, I always stumbled over the problem of definition. Specifically, where writing software is involved, “lowered quality” is generally only definable on a case-by-case basis, and where there will be an almost limitless number of cases!

To see what I mean, consider “lowered quality” in a conversation between me and a TV saleswoman. She has told me that this 50-inch flat screen HD TV is going for 25% off, and so I naturally ask her, “Why?” She tells me that the model is discontinued, for one thing, and this particular TV has a small crack in the casing at the back (which she shows me). Faced with those two pieces of data, I can certainly make an informed decision about whether or not to accept the “lowered quality”, in exchange for a cheaper price tag. And either way, it’s an acceptable resolution for us both, as she’ll just find someone else to sell it to if I happen to pass on it.

Compare that to the typical software conversation between me and a customer around “lowered quality:”

Customer: “I’m OK with the quality being traded off in order to get the features done sooner.”
Me: “So… You won’t mind if there’s lots of bugs when we ship it?”
Customer: “Well, what do you mean by LOTS?”
Me: “I have no idea. I can’t really predict, because as soon as we stop worrying about quality, all I know is: the bug count will grow. I have no way of knowing by how much.”
Customer: “OK, well, what SORT of bugs are we talking about?”
Me: “Again: no idea. After all, if we knew ahead of time which bugs would be in the product when we released it, we’d avoid introducing them in the first place. We can identify some specific goals, like performance numbers that have to be met, but generally bugs are very difficult to predict.”
Customer: “How about if we say, no more than 10 high priority bugs by release date?”
Me: “OK, that’s helpful. But we can’t guarantee to get below that number at the end, because there just may not be time. If we leave considerations of quality out of the mix during development, then by the time the bugs are being found, there will likely be a lot more than 10 high priority ones, and insufficient time to do anything about them.”
Customer: “This is a very frustrating conversation we’re having…”

Part of the problem is that the customer was envisioning “lowered quality” as meaning the equivalent of a discontinued line of TV products or a TV with a small crack in its case. She didn’t have in mind that, metaphorically, the Blue function (of Red/Green/Blue fame) might not work, that the image might be jittery, that the TV might shut itself off every 20 minutes, that one of the buttons on the front might not work, that one of the HDMI inputs was defective, or any of a thousand other things that might REALLY embody “lowered quality.” That disconnect, between what the customer believes that they’re getting when they agree to “lowered quality” as a priority, and what they end up actually receiving as a result of that decision, are rarely aligned when it comes to software.

And THAT’s why I don’t think you can trade quality for expediency, in the software world (in addition to all the fine points made in your blog post).

I meant this: below the speed/quality barrier, more speed requires an investment in more quality, meaning a short-term outlay of time and effort, which will slow us down for some time; above the speed/quality barrier, even more quality leads to even more speed. Perhaps a metaphor would help.

(snip)

In the process of describing the metaphor, I realize what I meant to write in the first place, and I don’t have enough room in this margin to make that happen. I need to go back to the drawing board, then try again. When I do that, I’ll share my refined perspective with you for your amusement and castigation.

Take care.

Quality is a difficult attribute to nail down. It means something different to everyone. And I have often seen it slow down dev teams, especially when the devs attempt to fix every defect a skilled tester can fling at them.

Yes, sure. Just as a useful product will far better than a useless one. The formulation above, however, is another implicit EITHER|OR comment, suggesting that if we have excellent code quality, we would somehow miss out important features.

That could be true ONLY IF code quality slows us down. Then it MIGHT happen that we would release with fewer features.

However, code quality does not slow us down. Therefore the comparison is not apt at all. Code quality makes us go FASTER. The high quality product will have more good features, not fewer.

“meeting the actual needs of the market beats quality (which is why we observe so many low quality systems surviving in the wild)”

There seem to be two sorts of quality at play here: “code quality”, which matters primarily to the developers and indirectly to the business, as developers take longer to implement stuff and the product has more bugs vs “product quality” which is a measure of how well the product provides value to the target market.

A product with poor code quality, but which has valuable features that mostly work for what the users try and do with them might well fare better in the marketplace than a product with excellent code quality, but which lacks the features completely.

The ‘cut quality to go faster’ view represents a lack of trust in the capabilities of the people actually building the product (whether justified or not). Dropping quality simply means you get garbage, later.

You’re absolutely right that keeping quality high requires continuous attention (no broken windows), balance (don’t try to do too much at once) and skill (focus on the right stuff).

I wonder, is the quality-or-speed view most prevailent in developers or non-developers?

There’s another effect that’s worth mentioning, which is the unpredictability of low quality code. If I have to make a change in a messy code base, it’s hard for me to tell how long it’ll take, which makes it harder for the business to decide whether a feature is worth the effort.