Stop Camouflaging Your Software Bugs

Termites and software bugs have this in common: they must be identified and managed quickly to avoid devastation. Termites can destroy the structural integrity of your home, and bugs can wreak havoc on profits, user experience, and a developer’s mental health.

Unfortunately, while physical characteristics like size and color easily identify insects, software bugs are determined by the less precise criteria of “anything that operates differently than expected.” But what happens when a bug has been in a codebase for too long? We start to take it for granted and ignore it. Denial is faster than debugging.

Jason Pollentier, Director of Engineering, describes a typical situation, “The app has a behavior… a niche or even obsolete feature, a configuration option, or even an implementation detail under the hood (e.g., cache)

• Whatever it is, it confounds the expectations of a naive user (aka everybody who’s not intimately familiar with the thing)
• Over and over, customers, QA, POs, or new devs run into it and think it’s a bug.
• An initiate patiently / proudly explains that no, it’s not a bug, you just have to do X, and it’ll be fine.
• We go on with our day with one more initiate who ‘gets it’ and thinks the thing isn’t a bug.

THE THING IS A BUG!!!

It’s like Stockholm Syndrome where the bugs are the jailers.”

Talk it out

“We prioritize based on what is going to make the most impact on the business that the software is serving and the customers interacting with the product. Sometimes, features are more important to the end user than a fixed bug; sometimes, it’s the reverse.” – Mary Legendre, Director of Product Management, Prioritizing Features and Bugs in Software Development

Remember that simply identifying a bug has zero cost, and documenting a bug is the first step to a solution. You don’t necessarily drop everything to fix the bug immediately. In some cases, a bug might be resolved by a single conversation. Perhaps one person on the team has a workaround, like using a setting in a code editor, that makes the bug invisible to them. Sharing the workaround is a quick fix that improves everyone’s experience.

When you feel like you are already overwhelmed, it can be tempting to put on blinders and stick to a narrow list of priorities to feel successful. But if you refuse to acknowledge a bug exists, you can’t gauge its impact.

Find the source

Once you identify a bug, it’s worthwhile to think about how to squash the individual bug and the underlying issue causing it. While some bugs are expected, many are preventable. Is this bug an anomaly or part of a larger pattern?

Avoid tunnel vision

“Folks who are not on the project are often the people who give, what feels like, the best reviews of PRs because they are often unbiased in the particulars of the app.” – Quinn McCourt, Software Engineer

Sometimes, a bug has been camouflaged by accident. After hours of staring at the same codebase, a team might need an outside perspective to jolt them into acknowledging that someone needs to be updated. We purposefully encourage pairing with other team members at Revelry to get a fresh perspective.

In one typical example, the naming conventions in the code desperately need to be updated. Still, everyone on the project is so used to it that they keep using names that have nothing to do with what they are describing anymore. But when outsiders review the code, they can easily see that the names don’t make sense. Listening to outside perspectives helps you keep your code bug-free.

Pay your technical debt

“If one’s everyday landscape is fire and brimstone, with about 18 things going wrong all the time, one gets used to being forced to accept hacky workarounds to do one’s job. Which, of course, propagates the issue…

‘hey this is a bug?’

‘That’s not a bug, THIS (waves in general direction of collapsing code) is a bug. You can get around that by doing….‘” – Stuart Page, Software Engineer

There are many technical ways to prevent bugs before they happen. Using tools like automated testing and continuous integration can save hours of development time. Specific languages also have unique time-savers. For example, TypeScript can prevent developers from accessing things that could be null, which can prevent many headaches.

But what happens if a project isn’t following best practices? Perhaps the codebase has no ability to run regular tests, outdated dependencies, inconsistent file structures, incomplete documentation, or highly repetitive code. Even though a company knows that a lot needs to be addressed, they keep delaying the fix.

We advise companies to be very careful with ignoring tech debt. If you wait too long to pay it off, it might be too late. Soon, your developers feel like they are fighting a hydra: every time you squash one bug, three more will appear.

Change the culture

“Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.” – Melvin E. Conway (Conway’s Law)

Building software is hard. It requires a lot of collaboration, time, trust, and money. If a team is not communicating well and the organization starts to feel dysfunctional, the code is in trouble.

• If developers are siloed and disconnected, they may not know how their code impacts other projects and create conflicts without realizing it.
• If the product owner doesn’t understand the scope of work needed for a feature, they may demand unrealistic timelines that force shortcuts and burnout.
• If a product manager is pressured to always prioritize features over bugs, critical bugs may be ignored for years.

At Revelry, our lean-agile process helps avoid many communication challenges. A consistent approach to identifying, prioritizing, and working through tasks keeps us all on the same page. We are also big believers in trusting your team to do their best work. Most developers take pride in fixing their bugs and leaving code better than they found it. No one wants to write bad code.

Find your empathy

“We all make mistakes. You’ve got to have as much empathy as possible. Because when something goes wrong, part of your brain thinks, wow, this person has no idea what they’re doing. And then you’ll remember that time last week when you did an even worse thing, or you also messed up, or you remember when you used to mess up. And then you’re like, maybe they just messed up? Maybe they’re not bad at their job. Maybe we’re all bad and good at our jobs. That’s just how it works.

You’ve got to be nice to people. I’ve discovered in the last year that software development is probably one of the professions where you probably need to be the most empathetic person possible.” – Stuart Page

Sometimes reporting a bug can feel like disrupting someone’s workday, admitting failure, pouring salt on a wound, or giving yourself more work. But don’t be afraid to talk about it. If there’s something you are constantly working around, you should consider it a bug and talk about fixing it. It’s probably blocking someone else, too.

Identifying a bug can do more than request a simple fix. One discussion about a bug could lead to more collaboration, an updated tech stack, improved communication, or even a reminder that we are all human and make mistakes. Don’t hide your bugs. Use them as guides to improving the foundation of your software.

---

Bugs Jason Pollentier Stuart Page