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.

Comments

Post a Comment

Popular posts from this blog

The Timeline of Errors

Image
As software developers, we see errors every day. They manifest as exceptions or segfaults or error codes, telling us that our code has gotten into a state we didn't expect. Their appearance often portends bugs. Though we groan at an unexpected stack trace, we should see an error as a form of automated feedback . Feedback can be fast or slow. We can put the discovery of errors onto a timeline. Errors appear at many points over the lifetime of the code, starting at the moment it is compiled. The further to the right that an error appears, the longer it takes for the feedback to appear. Compile time Compile time is the earliest we can receive feedback about an error. The compiler automatically does a number of checks to make sure the code makes some semblance of sense. The most powerful tool for compile-time feedback is the type-checker. The type-checker makes sure that only values of the expected type are passed around to the places that expect them. This guards ...
Read more

Assuming the Bugs

Writing code is all about making assumptions. Sometimes those assumptions are explicit, but more often we make those assumptions implicitly. We make assumptions about what kinds of parameters we will receive. We make assumptions about what kinds of values methods and functions will return. We make assumptions about the global state. The correctness of our code relies on the correctness of these assumptions. Bad assumptions can wreck our applicatons. We assumed that method never returns null, but turns out it does. Now we have an unexpected NullPointerException crashing through our stack. We assume that we will always average at least one element. Turns out someone wants to average zero elements. Boom, division by zero, ArithmeticException . We make so many assumptions through our codebases, at least a few are going to be wrong. Really, there are many, many assumptions that are wrong. These are bugs. These bad assumptions are all of our bugs. Usually, our assumptions are i...
Read more

Assuming Debugging

Bugs are bad assumptions . Debugging is the process of testing our assumptions until we discover the invalid one(s). Once found, we can then correct those bad assumptions. The following code generates blog post author statistics for a popular blog site. The statistics show which days of the week authors are making posts. Most of the authors post every day, and extra on Fridays and Saturdays to capture the weekend audience. It has at least one bug. @GET @Path("/authors/{email}/weekly-stats") public UserWeeklyStats calculateWeeklyStats(@PathParam("email") final String email) { final User user = this.userService.byEmail(email); final Map<LocalDate, List<Post>> postsByDate = this.postService.thisWeekGroupedByDateFor(user.id()); if (postsByDate.isEmpty()) { return null; } final Map<DayOfWeek, List<Post>> postsByDayOfWeek = new HashMap<>(); postsByDate.forEach((date, post) -> post...
Read more