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.
And so our attitude tends to be fairly defensive. We pretend bugs aren’t there. We try to persuade users that it’s meant to do that. We have a ‘them and us’ relationship with testers. It’s a negative response to negative criticism.
First off, we should recognise that this attitude is unhelpful. Pretending bugs aren’t there does not make them go away. Persuading users that the ‘bug’ is in fact a ‘feature’ makes users believe that the product is inherently poorly designed rather than merely superficially flawed. And obviously, you don’t want to piss off testers. You’ll only make them angry.
So how do we respond positively? While we’re trawling each individual bug in our defect list, it can be hard to find anything positive. So we always need to keep in mind why we would want a product ‘shit list’. Why do we want to fastidiously maintain a database that details each and every way that our product fails?
As discussed in my first post on this subject it is a good thing that defects are tracked. And as I discussed in my last post knowing the defects not only helps us improve our product but helps us become better developers and improve our processes. So the next product is better too.
If we can take this broad view, we can grit our teeth and admit that maintaining a product shit list is helpful overall. It still doesn’t make us like it. But we can go a step further and make our defect database more positive too.
In the past, I used Fogbugz to maintain my product bug list. So by definition, when I looked up something in Fogbugz, it was a bug, criticism, failing, whatever. More recently though, we’ve started to track all software changes using Fogbugz. This means that every piece of work that I do, whether ‘bad’ bugs or ‘good’ new features, is tracked though Fogbugz. As a result, there has been a subtle but significant blurring of the line between bugs and features. No really, this is a good thing.
Say for example I added a new feature to the product – lets say a list of search results. The tester takes a look and decides that there should be an option to sort the results. So he does what testers do and raises a bug report. And I get pissed off at him for pointing out defects in my code. This is how we used to work.
Instead, we now have a situation where the tester can add requests for features. So he looks at my new feature and tests it fully. It works, so he marks the feature as working. Warm fuzzy feeling for me! However, the spec stated that we should be able to sort the results, so he requests that as a new feature. And I’d much rather implement new features than fix bugs.
Don’t get me wrong. I know that I’m just mucking about with semantics here. But I really think this sort of thing helps. Generally it improves morale. During development (that is, before the product is even finished) it seems unfair to say that omissions are ‘bugs’. It’s like criticising an artists work before he’s completed it. Also, it’s far easier to get people thinking the right way if we’re careful with terminology. Inexperienced developers are often reluctant to raise ‘bugs’ as it seems a betrayal to their own team. Requesting new features on the other hand? Sure, that’s a good thing. And anything we can do to get bugs shifted into the ‘good thing’ category must be worthwhile.
Be First to Comment