Skip to content

Month: January 2010

Bugs part 3: Don’t shoot the messenger

I’ve spent the last couple of posts discussing developers’ attitudes to bug tracking. More often than not, it could be better. In this third and final post on how developers deal with bugs, I’ll discuss how we might improve our attitudes. Forgive me, but just this once I want to go all hand-wavey and go on about positive attitudes, constructive criticism and so on.

Would it come as a surprise to you if I said that developers see bugs in a negative light? Yes, when we see other people criticising our software, telling us that it’s not good enough, saying “no mate, it’s broke”, we take it as a personal insult. I can’t imagine why.

Bugs part 2: Towards perfection

There is an expectation placed on developers – and pretty much everyone else – that they must strive towards perfection. Failure is not an option. There’s a general attitude anyone who makes mistakes is not good enough. When mistakes are made, heads should roll.

There’s a nasty cycle where mistakes are ignored or at least forgotten about. First, we all assume that we are good at what we do. When mistakes (inevitably) happen, we assume therefore that they’re someone else’s fault. If the system does not behave the way the customer expects it to, we assume it was poorly specified. If a bug makes it to production, we assume that the tester failed. Even if it’s decided that the bug is our fault and our fault alone, we assume it was a one-off mistake – a bad code day or whatever. Or else assume that it’s the sort of mistake that we’d have made a year or two ago but we’re too experienced to let that sort of thing happen again. Either way, we assume it won’t happen again. Because we’re good at what we do.

The big problem is that we assume that we’re perfect. We’re not. There’s a simple test: Have you ever made a mistake? If the answer’s yes, you’re not perfect. If the answer’s no, you’re a liar. And not perfect.