Suppose you notice your car is suddenly handling poorly going around turns. You check under the hood, and around the outside. Then you notice that the tires are low on air. That must be the problem. You add air to the tires and forget about it. 2 days later the car starts to float while driving on the highway. Once again the tires are low on air.

Do you

• continue to fill the tires every few days?
• Or get the tires serviced?

Many software teams take defects as a natural part of software development. They accept defects, fix them, and keep coding. They repeatedly add air to the tires. Sometimes they seek less expensive ways to repeatedly add air to the tires.

The various defects - handling poorly in turns, and floating on the highway – both point you toward the bigger problem: the tires are leaking air and should be serviced.

Critical software defects must be fixed, just like adding air to the tires. But if you follow the defects further they can help you uncover broader system wide issues.

Treat software defects as something useful. While finding and fixing them, you have paid dearly for them. Each defect contains information about your software process or design. It is a signal. Use defect reports to continuously improve the process and design in order to prevent that class of defect from reoccurring.

If your process iterates per week, you can collect defects per week and improve every week.

If your process is waterfall and goes though a 12-month cycle, you have a chance once a year to improve based on the defects of the last year.

Defects are hard won and expensive information.

The bright side of defects is that they give you the information to fix the underling problems in the process and design of your software. Listen up! Service the tires.

And Drive safely.