Manager’s Role for Bug-Weeding

Thanks to Brian Marick, I read Dave Thomas’s Weeding Out Bugs. Much of Bug-Weeding is developer turf. But here’s what managers can do to help:

  • Look at defect counts by module. When you see a module that has more than it’s fair share of defects, start asking questions about what the developers are considering. You’ll all need to weigh the risks of wholesale tossing and rewriting, but the manager’s job is to start the conversation if the developers haven’t already.
  • Make sure the developers fix builds before they go on to more coding. (I like to make sure the project team can build at least once every day. If your project team can’t already build frequently, consider a project to make it easy to build every day. And for those of you with humongous projects where you only build every week or so — continue at your peril. Break apart the builds so the project team can create a new build every day.) Developers have bad-code days. If you discover someone (or ones) had a bad-code day yesterday, you have an opportunity for very quick feedback to the developer(s) so he or she can fix his or her defects. If developers fix defects before they go on to more coding, you’ve reduced the overall defect counts. And you’ve really made a milestone, not just met a date where people claim they’ve met a milestone (“except for all those bugs we have to fix”).
  • Monitor the cost to fix a defect. Clarke recently wrote about Quantify the cost of reworking bugs?, to see how long bug-fixing added to the schedule. Managers can monitor if the finding cost is higher than the fixing cost. The higher the finding cost, the more time people are spending in defect-prevention activities. The higher the fixing cost, the more time people spend in defect-fixing activities.
  • Monitor the fault feedback ratio, the number of bad fixes to total fixes. My rule of thumb is a project can make progress with an FFR of 8% or less. More than 8% and developers are spinning their wheels.
  • Monitor system size. Back when I was a developer working on a substantial system, I was amazed at how my end-of-the-release defect-fixing caused my code to vanish. I now know I was refactoring at the end. It’s better to refactor as you go along, but sometimes, you can’t see the simplicities until the end. (A good reason to make lots of little ends.) Software follows an “S” curve of creation: some code starts, there’s a fairly dramatic increase, and then a tailing off. When developers refactor their code (the tailing off), they lose up to about 1/3 of the total number of lines of code (my data, yours may vary). If developers tell you they’re done, but the total LOC count doesn’t go down, you can look for other ways to test that doneness.

Managers can’t just monitor the schedule. (I can always claim to be done. The real question is how good is my work product in a given amount of time.) It makes no sense to only monitor product creation and cost unless you also monitor defect creation and cost. Then you can avoid the weeds.

Leave a Reply