Practice 2. Be Uncompromising about Defects It is vital that you adopt an uncompromising attitude toward defects. The goal is to avoid a defect backlog, where there is a list of open defects that is too large for the team to deal with immediately. Defect backlogs are evil and must be avoided because: Defect backlogs burden teams with repetitive searching, sorting, and categorizing tasks that waste time and take away from productive work. A backlog, by definition, means that more defects are being carried around than can be reasonably dealt with. The number of defects makes it more difficult to find the defects that must be fixed, the defects that customers repeatedly encounter and can't work around. A defect backlog is a strong indicator that new features are being developed on top of defective code. The larger the backlog, the greater the chance the backlog is never going to be eradicated. I have seen cases where teams were carrying around backlogs that would take over a year to fix, even if all they did was fix bugs and no new problems were introduced! The larger the backlog, the greater the chance that defects are going to be shipped to customers and that customers will find defects that they can't work around, so you're going to have to send them a patch. This is expensive for you and your customer. The greater the time between when a defect is introduced and when it is fixed, the greater the cost of fixing it. Carrying a backlog thus means that you are implicitly accepting higher costs of development and future change.
How to Avoid a Defect Backlog Be ruthless: When a defect is reported, decide as quickly as possible to either fix it or get rid of it, preferably by marking it with a special state to indicate that it won't be fixed along with an explanation as to why. This way you won't lose the information. Fix regressions, where a feature that used to work stops working, immediately. Regressions put the product into an unknown state where users won't be able to trust it and developers won't be able to make changes with confidence. To achieve sustainable development, regressions must be fixed immediately, before any other changes are made to the product, even if that means that work on some new feature must be stopped to fix the regression. Once you have decided to fix a defect, do so as quickly as possible, and for as many defects as you can manage. Understand what caused them and how to prevent them in the future. Fix all the known defects in a new feature before moving on to work on the next feature. Then, once you move on to the next feature, be ruthless with any newly reported defects.
The Value of Being Uncompromising I have worked on and with quite a few teams that were uncompromising with defects. The common thread in all these teams was that the number of known defects in our product was constant to slightly decreasing over time, even as we added new features and rewrote large sections of the code. Every team used different techniques and practices to accomplish this. What mattered was the mindset. |
Put More Effort into Defect Prevention Than Bugfixing The most important point about being ruthless about defects is that you need to put more effort into preventing defects than into fixing them. Defect detection is still vital; it's just that defect prevention is even more important. Being ruthless about defects and trying to avoid the accumulation of a backlog is one thing, but if your product doesn't have safeguards in place to prevent defects from getting to your QA department or customers, then you are still going to get a backlog, no matter how fast you fix and classify your defects. Defect prevention is described in detail in Chapter 5. Use a Defect Tracking Database, but Don't Build It Yourself! Being ruthless about defects, of course, assumes your team is using a defect tracking system. If you don't have one, there are many good commercial, free, and open source systems that can be downloaded and installed pretty quickly if you don't want to purchase one. A good example is bugzilla (http://www.bugzilla.org/). Because there are so many decent defect systems available today, this is a perfect example of a tool that should never be developed internally. Focus on what makes your product unique and on shipping it! |
Being Pragmatic about Defects If you are starting a project with known technical debt or are concerned that your product quality may slip, there are a few things you can do: Insert bug fix-only iterations between feature development iterations. If product quality is slipping, you'd be surprised by how many users appreciate a stable product with a few focused features. Set some quality-related exit criteria for your iterations. Then, set the rule that the team can't call an iteration complete until the exit criteria are met. An example exit criterion might be "There can be no 'stop ship' defects in the product and no known regressions." Another might be "There can be no known open and unresolved defects" (to reinforce the need to be ruthless). These exit criteria add some extra discipline to iterative development through having a clear goal. A variant on the previous point is to let the team decide (the team includes the users or user representatives!) when the quality is good enough to move on to the next iteration.
These ideas might cause some people to balk, but I think you need to do what is best for your project. Your goal is to ship repeatedly, and with the least amount of wasted effort. I have used or seen each of the above suggestions on various projects, and they work. However, you do need to be careful, because you should not need to regularly rely on these nor use them for any extended period of time; disciplined iterative development alone should be sufficient. |
