Working in a software company comes in two flavours - the green-fields, dream-plan -build-software bit, (which is fun) and the dreary endless bug reports that come from testers and customers (which are not fun).
As a very depressed project manager once said :
At TOWER Software, as these bugs arrive, they are prioritised according to a simple scale:
1) Urgent Fix
2) Fix ASAP
3) Fix
4) Fix if Time
5) Won't Fix
It's pretty self explanatory, so I won't go into the bleeding obvious, but each day, the team goes through and assigns a significance score to each bug. Then we hand them all out and get to work. That process is called triage, after the medical hospital waiting system. The goals might seem pretty similar -you might think "Ok, you want the bugs that are really bad to be fixed first - not unlike the hospital scenario where the man with the axe protruding from his head gets treatment before the snot-nosed baby".
Well, yes. But also, no. Therein lies The Secret.
People (usually testers, but I generalize and digress) have this crazy idea that the aim should be to fix all the bugs, and ship with none. Well, I don't know what planet these people come from, but all I have to say to those people is this:
The big secret difference between the medical Triage and Software Bug Triage is this:
We're not trying to decide which bugs to fix. We're trying to decide which bugs to ship.
That way, we only ship with bugs that people a) won't find or b) won't mind.
Each time we find a bug we are prepared to ship, it's like a fairy gets it's wings somewhere.
At the moment, as we inch towards the 1.0 release for ice, the only thing climbing higher than the team's stress levels is the triage bar. It's getting pretty hard to get a bug fixed right now.
This comic makes a joke out of it, but the fact is, as you get closer to shipping, you just can't wobble the jelly. Remember that as soon as a developer fixes a bug, there's a risk that they'll add a new bug, or break something somewhere else. It's a constant balancing act and one that takes incredible attention to detail to get it right. .
That's not to say that I don't think you should fix bugs. You should. And in a perfect world, where we could push a button on a wacky time machine-o-tron and stop time, and fix absolutely every bug, and then ship - well, then that would obviously be a better option. (Obviously I left out the bit about where you would start time again, otherwise there would be nobody to buy your instantly developed and totally bug free product.)
But the reality is that we don't have one, and so we try to make most of the people happy, most of the time.
Oh and if anyone has such a machine, can I borrow it for a week? Only one, honest....
As a very depressed project manager once said :
"The software is not finished until the last user is dead"
At TOWER Software, as these bugs arrive, they are prioritised according to a simple scale:
1) Urgent Fix
2) Fix ASAP
3) Fix
4) Fix if Time
5) Won't Fix
It's pretty self explanatory, so I won't go into the bleeding obvious, but each day, the team goes through and assigns a significance score to each bug. Then we hand them all out and get to work. That process is called triage, after the medical hospital waiting system. The goals might seem pretty similar -you might think "Ok, you want the bugs that are really bad to be fixed first - not unlike the hospital scenario where the man with the axe protruding from his head gets treatment before the snot-nosed baby".
Well, yes. But also, no. Therein lies The Secret.
People (usually testers, but I generalize and digress) have this crazy idea that the aim should be to fix all the bugs, and ship with none. Well, I don't know what planet these people come from, but all I have to say to those people is this:
A ha ha ha ha ha ha ha!There is no software with no bugs. All software projects have bugs in them. All of them. Leaving aside the definition of a bug, just think about the bugs you live with in the software you use. Did you ever have Microsoft Word just spontaneously shit itself and delete your document? You know you did. Do you know why Microsoft implemented system restore points in Windows XP? Because The Bugs live with us, baked into our binary apple-pie that we consume every day.
*gasp*
*breath*
A ha ha ha ha ha ha ha!
The big secret difference between the medical Triage and Software Bug Triage is this:
We're not trying to decide which bugs to fix. We're trying to decide which bugs to ship.
That way, we only ship with bugs that people a) won't find or b) won't mind.
Each time we find a bug we are prepared to ship, it's like a fairy gets it's wings somewhere.
At the moment, as we inch towards the 1.0 release for ice, the only thing climbing higher than the team's stress levels is the triage bar. It's getting pretty hard to get a bug fixed right now.
This comic makes a joke out of it, but the fact is, as you get closer to shipping, you just can't wobble the jelly. Remember that as soon as a developer fixes a bug, there's a risk that they'll add a new bug, or break something somewhere else. It's a constant balancing act and one that takes incredible attention to detail to get it right. .
That's not to say that I don't think you should fix bugs. You should. And in a perfect world, where we could push a button on a wacky time machine-o-tron and stop time, and fix absolutely every bug, and then ship - well, then that would obviously be a better option. (Obviously I left out the bit about where you would start time again, otherwise there would be nobody to buy your instantly developed and totally bug free product.)
But the reality is that we don't have one, and so we try to make most of the people happy, most of the time.
Oh and if anyone has such a machine, can I borrow it for a week? Only one, honest....
Hey you! I followed the link from your comment on Eric's blog. You say he put it more eloquently. Yeah I guess, but yours is great too (and I've only just read one paragraph). Good thing I found your blog, now I have another good software blog to read. Shweet.
ReplyDelete