Advice for Simon: How good Dev teams fix bugs
Submitted by Erik Petersen on Sun, 02/03/2008 - 23:43.
general software testing
Simon posted to a software testing discussion list:
I’m working on a project at the moment which is slipping day on day and one issue we’re seeing is that the development team refuse to believe they can estimate how many defects they can fix in a certain time frame. I’m trying to influence them to do so (as is my manager) but having not been a developer (apart form creating the odd web site) I don’t know how true this claim is. Personally, I think by breaking a task down, or using a gut-feel based on experience you can estimate anything but they disagree stating that until they investigate they don’t know how long a defect will take to fix. Does anyone have any experience or ideas which could help?
I replied
You have a serious but solvable problem. You have reasonable questions that a decent dev team should be able to answer. Here’s what I’d be doing.
First off, I’d add context to the bugs, what should be assigned a release and what can just fit in. You have to fix the important things first. If they are ranked by severity or priority, the most important of them should be assigned to a release.
One of your key goals should be coverage. I’m presuming that the enhancements are significant. If that is the case, some bugs will be local and others will be blockers. The blockers stop you getting the coverage you need and may be hiding many other bugs. These need to be assigned to a release.
The rest can go into a hopper that slides into a release when possible. If this is an agile project , some things will suddenly disappear from the release at the last moment if they didn’t get done done in time, but they must be finished to go straight into the next release.
Next the devs need time to do their work. They need to allocate a slice of the release for defect fixes. There should also be some slack time on top of that in the release framework, to allow for some overrun from defect fixes or whatever. One issue I have faced is an obsession with velocity, always adding new stuff, and pushing aside defect fixes. This is just piling on Technical Debt (see http://www.martinfowler.com/bliki/TechnicalDebt.html for more). They may need time allocated in the schedule for analysis, and estimation. On top of the enhancement and bug fixes, they should also allocate time for improving the code as well (a.k.a Refactoring http://www.refactoring.com/).
It turns out it wasn’t an agile project, but as I said the principles still apply. The other interesting thing is typically estimates only take delivering the code in a working fashion into account. Agile approaches with TDD at least deliver code that tests itself and is typically simplified at least enough to write the tests. Important maintenance issues like refactoring and reducing technical debt are typically overlooked in tradtitional development, which is why the agile approach of revisiting them is so good.
Some enablers for this
I’m presuming this is an agile project. I’ve thrown a few buzzwords in for you on that basis. If it isn’t, the principles still apply.