Brick laying and bug reports
Giving great customer support is a holistic process. Even if everyone’s a natural at talking to customers, nothing will actually get fixed if your developers avoid bugfixing like the plague. Which is a slow death, eventually customers get fed up and leave if their bugs remain unfixed.
Bugfixing? More like “ugh, fixing!”, amirite?
For a lot of developers, bugfixing is a slow, agonizing nightmare. Bugs languish and they shudder in dread as a new report lands on their desk.
But why is that?
We’re quick to come up with a myriad of reasons:
- “Customers don’t tell us the whole story, I feel like Philip Marlow”
- “Our support team could do a lot better at writing bug reports”
- “I spend more time looking for info instead of actually fixing it”
Save the last point, that’s just the nature of the beast. It’s not the customer’s job to give us a perfect bug report. Even a perfectly trained support staff will need a developer’s insight on a bug.
But there is a lot of wasted effort when fixing bugs, just not where we think.
One Weird Trick™
Pulling from history, let’s take a look at Gilbreths’ motion study of brick laying:
See how there’s a lot of stopping and reaching for what you need at that moment? Really, this is no different than:
- Having to look up the original conversation with support
- Trying to figure out exactly what’s wrong
- Finding the constellation of data that causes this bug
- Figuring out the steps to reproduce the problem
The brick laying study is unique in the Gilbreths’ work because the improvement was exclusively caused by adjusting the preparation. By simply stacking the bricks on palattes so a brick’s always within arm’s reach, the Gilbreths increased the productivty of brick laying by 100%.
Preparation is key
Oftentimes, develpers have to check that a bug actually isn’t a critical issue. So they don the detective hat, dig through the log files, read the customer’s email, and figure out what’s going on.
The problem is that unless it’s a critical bug, all this work gets thrown away under the guise of being “more productive.” And at first glance, it works: you’ve handled the interruption and you’re back to work. But now you have to double back before you can actually fix the bug.
It’s like we gather all the materials, put down the first few rows, then throw everything in a landfill and call it a day. Tomorrow we’ll have to start from scratch for no good reason!
So, how do you make bugfixing less horrific? You stop doubling back on your work! Take the time to put your bricks onto palattes the first time around. It’s not like the bricks magically appeared in Gilbreth’s study, the bricklayers had to carry and stack them. We just tend to toss the bricks unless we need them right now.
Bugfixing is extremely unpredictable. A “simple” cosmetic bug could actually be a symptom of a huge issue that’s been ongoing for months and will take days to fix. It might take hours of pouring over log files to find the source of a bottleneck.
✨Oh, and each bug is a unique and beautiful slowflake!✨ 😒
Trying to optimize the actual act of bugfixing is usually a waste of time. It’s a skill for fixing unpredictable problems, built on intuition and context. Your best bet is to improve the prep work. Make bug reports easily readable, put the relevant info within arm’s reach, and don’t lose any progress you’ve made. Like how Gilbreth improved brick laying, making your bug reports easily accessible and reducing wasted motion can bring huge improvements to quality of life and productivity.
When I add relevant log entries, chat quotes, or screenshots to a bug report as I go along; that bug’s a lot easier to wrap my head around later. Integrating our support system with our issue tracker means there’s always a link to our conversation with the customer, making detective work and writing replies a breeze. Unsurpisingly, the fewer hoops I have to jump through, the happier I am to fix a bug.
And the hoops feel twice as bad the second time around.
What now?
The next time you get asked to look into a bug, make sure to braindump all your research before you get back to work!
Doing the prep work ahead of time and not throwing away the work you’ve already done are the biggest challenges when it comes to bug fixing, mainly because they’re silent killers. Developers are often quick to try to delegate it to support staff, or blame support/customers for not writing good bug reports; but they often waste a lot of time and effort doubling back on the worst parts of bugfixing.
Further reading
If you want to read a bit more about bug reports:
- I highly recommend Sifter Academy. In particular, “File Great Bug Reports”, which was a huge influence on my bug report habits.
- I outlined workflow adjustments you can make to get back to customers faster
- I also wrote “Stop giving shitty emergency support”