Too Many Bugs - Conclusion

This is the final part (for now) of the thoughts I’ve collected on improving the relationship between software developer and QE to find high-risk bugs sooner. You might want to check out parts one, two, three and four before continuing here.

To some people it might seem that a lot of what I’ve written about here is common sense. The condensed version of this text might be “go talk to QE”. But surprisingly there are exceedingly few people that actually do it. QE, or any other group for that matter, is a mysterious team with bad intentions that lives on the other side of the fence we through our software over. Working with QE over Bugzilla and email is like a 2400 bps modem. You just don’t get what you need over it. Software developers are typically even more prone to this reclusive behavior due to the kind of people attracted to the field. I struggled with the same social problems for years, usually with less than satisfactory results. Eventually I found a way to work with others that works well for everyone. I had to struggle against my strongly introspective personality and force myself to communicate verbally, in person, with people around me and affected by my work. Why? Because it didn’t seem like anyone else was doing it and there had to be a better way to deliver high quality software that people wanted to use.

By paying attention to these things the quality of my technical work improved and my visibility to people both on and outside of my teams skyrocketed. I’ve made an effort to improve how I work with others and in doing so I’ve made a name for myself. Possessing superior technical skill is of little use if no one recognizes it. Think about that for a minute. You can be the greatest programmer of your generation and you’re not going anywhere if you can’t convince others you’re worthwhile.

Oh yeah, what effect does this have on the bug triage meeting? If you’ve read this far then you know you’re showing up loaded with ammo. Every bug you talk about is going to be important because you’ve eliminated all the small ones along the way. Imagine being in a room with your peers and a cross functional team where every word you say is inherently more valuable because you’ve done your homework. You’ve put in the effort to make this meeting more valuable for everyone else that attends. You’re not wasting their time by even looking at bug 34987 that only had a minor impact on documentation. You’re in front of an audience that wants to discuss things that matter, business or technical.

No one wants to get up in the morning and think, “I want to sit in a bug triage session all afternoon today and again tomorrow”. In this meeting you’re able to talk about every bug as it comes up. You know the issue, you know the root cause and you know what kind of scope it takes to fix the problem. That’s the kind of information that’s needed at bug triage sessions. That information helps to determine the severity and priority. It let’s people decide whether or not the bug needs to be fixed right now and that is exactly the point of bug triage meetings. People will notice that you’ve done your homework and they will appreciate it. It will get you noticed. People will realize you have in-depth technical skill and you can work well with others which almost guarantees a position as a successful technical lead and it will open up a lot of other doors in your career. What, you just wanted to make the bug triage meeting shorter?

Well, like software this paper isn’t perfect. I’m certain there are missing topics, incorrect statements and gaping holes in logic and arguments. There are entire books written on this subject and I don’t have any delusion that I’ve covered even one one-hundredth of 1% of the social issues that hold our industry back from consistently releasing high quality software, on time, on budget. But, like I do for my software, I keep a list of known risks for this paper and I’ve decided that it’s finally time to ship it, bugs and all. Congratulations on reading the entire thing and bigger congratulations for just skipping to the end if that’s how you got here. If you’ve found this to be worthwhile please submit it to Digg, Slashdot, StumbleUpon, del.icio.us or whatever other social network you use. Also please leave your comments and discuss what I’ve written. Feel free to add topics you think would be interesting.