Damn, we’re at part five already? You might think that I’d be running low on material by now, but fortunately I have witnessed a horrifying number of ways in which people have tried to run a software project, most of which ended in disaster. This week we’re going to touch on something that I’m still dealing with at least once a week…
The OMFGWTFBBQ Method of Bug Triage
Because the people working for you are software developers, the people working for you suck. You know this is true because I have a blog and I just wrote this. Because the people working for you suck, they are going to write sucky software that is filled with bugs and things that have made a horrible abomination out of your grand vision. It isn’t your fault that they couldn’t understand your requirements; you gave them brand new ones to work to every day (a strategy we’ll talk about in a future post), so they should have been able to easily translate your brilliant idea into perfection. They failed because they’re not passionate! They wanted to take baby steps and build things slowly and incrementally, but that’s a recipe for mediocrity, and you’re not mediocre! You’re special!
Anyway, so they’ve actually managed to stop playing solitaire (or whatever software developers do when they claim to be working) and produced a system. Even though writing software is so easy that you’re 14 year old nephew can do it (he did a web page for your shuffle board club, and that’s just as complicated), your developers managed to screw it all up, and there is something that isn’t working exactly like you pictured it. The *only* way to react is to panic and call an immediate meeting with everyone in the company. Be sure to include people that have nothing to do with the software, like your wife and any nearby hobos. Make as big a deal about the issue as possible. It doesn’t matter if a button is left-aligned when it should have been right-aligned, you must demand that the developers immediately stop what they’re doing and work on the problem. Accuse them of not listening to you and ignoring your issues, too, because that will help motivate them. I mean, you just told them about it, why is this bug not already fixed? Storm out of the meeting and stay in as fowl a mood as possible for the next three days.
While it may seem like a lot of work, you actually have to repeat this process every single time you find a bug, no matter how small, otherwise the developers may start to become independent and try to "prioritize things by how severe they are". Your button alignment issue is every bit as important as that little "data corruption and loss" bug they made up. Try to do this every day, if possible, by creating a OMFGWTFBBQ "Issue of the Day".
Why this is a TERRIBLE IDEA
Despite what you may think, we (developers) do actually listen. If we don’t fix your bug right away, there’s probably a really good reason for it. It could be that fixing the bug will cause some other problem that we haven’t figured out yet, or that there are other more urgent bugs that we need to fix first, or that it’s a complicated bug and is taking a while to fix. Freaking out about every little bug and making an inquisition out of it stresses everyone out, wastes time, and lowers morale (which is actually a bad thing). Instead, report the bug to the team and try to go on with your life. The fact that there is a bug in the system doesn’t mean that someone was screwing around or that someone doesn’t respect you (or that they’re not passionate about what they’re doing). Believe it or not, building software is HARD, and we do make mistakes from time to time.