Let’s face it. Software we build is going to have bugs. Anytime you are writing a large system in the face of changing requirements, something isn’t going to work. It might be that a requirement wasn’t met, or changed during development. It might be that a spec was misunderstood, or that we as developers didn’t immediately stop and ask the customer when we had a question. Or it might just be that we introduced a defect into the system because, heck, that’s what we do sometimes.
Since we know we are going to have bugs, we want to have something in place to keep track of them. In some shops this might be a spreadsheet, or a bug tracking program (like FogBugz or OnTime), or a stack of red index cards. We’ll want to make sure we track things like reproduction steps, the error message, date and time, and other relevant information (maybe hardware, browser, etc).
However, there is one key piece of information that perhaps shouldn’t be captured – who created the bug. “Surely you jest!” one might say. Why wouldn’t we want to track defects by developers?
Well, why would we /want/ to track bugs by developer? It all comes down to metrics. What team wouldn’t want to be able to point at a pretty chart of all kinds of crazy metrics and say, “This is where our problem is, let’s get it fixed”.
But, is that what really happens? Several months ago I observed a project which was a bit vague, and the exact requirements of what was trying to be accomplished were difficult to nail down. The developer on the project was ultimately fired after not being able to deliver it.
Looking at the metrics for the project, it was easy to see why the developer was let go. He wasn’t accomplishing enough. He had “enough” time to figure out what needed to be done. And in the fast pace environment that it was, if he was having trouble with that, well, we could all sleep better knowing that he wouldn’t have made it in any of the other projects.
Before he was put on the project, 4 or 5 other developers had worked on it. All of them had difficulty trying to nail down the requirements, get a clear direction, or deliver a product. All of them were ultimately moved to other projects.
I bring this up because of a recent quote I read in Lean Software Development:
The vast majority of defects have their root cause in the development systems and procedures, and trying to attribute defects to individual developers is a case of shifting the burden. We are not looking for the root causes of the problem if we trace defects to individuals; rather, we are hiding them.
We are hiding them. This resonated with me. How often have we fixed a bug, knowing that we are merely sweeping the root cause under the rug, hoping it doesn’t happen again, rather than figuring out what caused that bug to happen in the first place, and fixing it. Granted, we may not be able to stop the root causes of every single defect or bug, but I’m sure developers can certainly do better than what they do now.
So, in the above example, maybe that developer didn’t fit in. But maybe there is a root cause, a symptom of a greater sickness, that needs to be addressed. All the xUnit tests in the world won’t help you if you can’t communicate with your customer, and all the communication in the world can’t help if we still can’t figure out what needs to be done, or what it even means to be “done”.
Let’s figure out what really is wrong, and fix the problem. That’s what makes us agile, and succesful. Fixing the symptom just hides the others, and only makes us sick. And I’d rather use my time off to go to the beach then lie in bed, wouldn’t you?