Friday, June 18, 2010

Only Quality Matters

If your code doesn't really work, then it doesn't matter how quickly you wrote it.

Abandoning quality in pursuit of speed is a fool's errand. It has been discussed plenty of times in about any management book you want to look at, and especially by the brilliant minds like Deming.

If you write your code badly, you can release it without awareness of bugs, and that takes it off of your plate. You may be rewarded or recognized for your quick work. It feels good today. Your team is recognized for being heroes within the company because you are smart, and get things done.

But tomorrow a customer tries to use it and it fails. The customer is no longer happy that the feature was delivered, because it's junk. In fact, as far as the customer is concerned the whole product is now junk, your company is junk, and the developers are pure rubbish. Loss of good will. Think how you feel when you get the Fail Whale, and you are a friendly customer and unusually forgiving. How do you feel when your cable provider or cell phone service has a hiccup, or when your windows mobile phone has to be rebooted. Normal people are much less forgiving.

Now that failure is reported (if you're lucky) and someone in product support hears about it. They feel less proud of their affiliation. They push to get a change made, but the programmers 1) are busy on something else, and 2) take a long time to find the bug. The product support queue grows. People are employed now to track mistakes and to try to run interference with unhappy customers.

The failure isn't just reported to the vendor, but to all the customer's bosses, who begin to question their vendor relationships. A few bugs now and then, they might be able to tolerate. but constant performance and behavioral bugs will have them holding the contract in one hand and a lighter in the other.

People are employed to fix the bugs, and to test the code to be sure the bug is gone. A few tests written TDD-style would have saved a lot of work, money, and hard feelings. But you were in a hurry.

If the code doesn't really work, then it does not matter how quickly you wrote it.


  1. Or as Deming put it:

    The part that really blows my mind: "The aim of this chapter is to show a stable system of trouble in a manufacturing plant, and to explain that, since the system is stable, improvement of quality is the responsibility of the management."

  2. ...and as someone else said "If a project doesn't deliver value for the users, then all other measures of success are meaningless"

  3. Note that if it really does work, time-to-market suddenly matters.