Love your Bugs
Here's how the conversations always start;
QA: "We're finding some bugs"
PM: "Why are there bugs? The requirements were perfect."
DOCS: "Should we document these bugs?
NPI: "I'm not trialing software with bugs in it!"
DEV: "Not my code."
SALES: "Don't worry about the bugs, I sold them 6 other features you haven't even started yet."
During the development cycle this is how it is, day in and day out. You're building software (sometimes at an insanely rapid rate) and bugs are being reported (and you have the stress of the release going out into the field for the first time). It's life, if you can't deal with it, go do something else (and that goes for all the above disciplines, bugs and software will forever be married). If you are writing code at this very moment, I hate to break it to you but you've just built a bug.
Am I jaded? Hell no, I'm being honest (and realistic). When you start to write new code, you're building off of what you know (or what has been given to you). Even if you know the system inside and out, you will make a mistake, you might not know it, but you'll make it. Why? Because once QA gets that new feature there job is to rip it to shreds, forget the Happy Scenario, they want the Alternate Scenarios, they want the Edge Cases because that is their job. And when the bug comes back to you (the Development Manager) its your job to go - "Yeah we're gonna hit that in the field, good find" or "Yeah installing our software on Linux when its meant for Windows is never gonna happen... ever".
So there it is - Deal with the bug or Close it down - your job is done, move onto the next one.
Now here's where things get dicey - What about when you know about the bug, but its not that high a severity or you don't think people are going to be using this feature too much in the release so it can be pushed out. What happens than? Well you can take your bug and push it out to another release down the road, and you can document for your customers and you can then forget about it AND eventually deal with it later. I'm not a fan of this approach for a few reasons;
- If you don't think people are going to use the feature much than why are you building it?
- What is the calculated lost effort to your organization from this bug? Docs now has to write about it, NPI has to be aware of it in case they run into it and when your customers call to complain about it, CS will probably spend time trying to diagnose it up until the point of discovery that it has been pushed out to the next release. This is time loss if you had of just fixed it in the first place.
- You've pushed out your product leaving you with a feeling of not really having hit the bar because let's be honest, who wants to put out a bad product where you say to the customer "yeah... don't click there".
Here's the thing about bugs - they have a different meaning to everyone. You could have the best process in the world, but you will never to be able to forecast which features your users are going to use. And that bug you just pushed out because you thought someone wasn't going to use it, well that just happens to be the whole raison d'etre for them buying your software in the first place.
So when someone finds a bug, don't get mad, or think of it as mass failure, look at it, understand it and solve it so it never happens again. I tell my team that every bug you resolve is one less Support guy asking you why something doesn't work and the last thing you want is the support line starting at your desk.