Bug Hunts: Better Together

Bugs are demoralizing. Bugs are draining. Bugs are frustrating. Bugs suck.

Nobody really wants to have bugs, and nobody really wants to be the one who has to track them down. Bugs are a reality of software development. They happen in even the most meticulously managed software. They always seem to come from the obscure or not-understood part of the code. They give error messages that make no sense and are completely unhelpful. I'm looking at you, NullPointerException and equivalents.

Getting assigned bug tickets is the software development equivalent to latrine duty. It is a necessary task that needs done, but no one wants to do it. A developer could spend hours or even days banging their head on their desk just trying to figure out what could possibly be causing the error. All the while, they are not creating new business value.

For some team members, finding where the bug is coming from is easiest. For others, discovering what is causing the software to get into a bad state in that location is a specialty. For yet others, knowing how to fix the bug is their particular skill. But rarely does one team member have the deep knowledge needed to find and fix any given bug on their own. The problem is particularly chronic in a large, convoluted legacy code base.

Can we make bug hunting any better? If different team members each have the different necessary skills, we could go on bug hunts together instead. Rather than a single developer struggling to find the fix, the whole team can put their heads together to squash the problem at hand. By bringing each of their respective skills, bugs can be corrected faster and better than a single developer might do on their own.

With more eyeballs, the bugs become shallower. But there's more to it than just that. A single person struggling becomes demoralized and drained. Together, team members can support each other. At the very least, one person doesn't feel so silly if other people are struggling too. The team forms a loop of positive reinforcement. The team also shares knowledge about the buggy part of the code as they reason through the problem. Unclear parts are questioned, and tricky parts are brought to the surface for refactoring.

Bug hunts are better together. Not only are bugs more easily fixed by a group, but the team gets better by the experience.


Popular posts from this blog

Trying Out FreeBSD

#FOChaCo: Fear of Changing Code

This One Subtle Bug You Might Not See Coming