Little Bugs, Big Problems

Software Engineering Manager: “Why haven’t you finished this bug? It’s been in implementation for three days… it’s just a bug, it shouldn’t be this hard.”
Developer: “...”

This interaction is common in software engineering. In this article, I’ll discuss how bugs are perceived by management, product owners, developers, and others involved in the development process. I’ll elaborate on perceptions of priority, work effort, and impact with examples from my experience.

Three common themes with bugs in past organizations:

1. UI Bugs are Top Priority: Management and product owners often see non-UI bugs as less important.
2. Bugs are Easy to Fix: Bugs are perceived as less complex than creating new features.
3. Developers are too Skilled to Write Bugs: Insufficient code reviews lead to bug-prone codebases.

Why These Perceptions Exist

UI Bugs are Top Priority

Some managers and product owners prioritize the visual interface as the most valuable part of the software, disregarding how functionality issues elsewhere affect the interface.

Bugs are Easy to Fix

Teams think bugs are easy to fix because the feature’s code is already written. However, it often requires more than a few tweaks.

Developers are too Skilled to Write Bugs

Without an engineering framework, the development process becomes disorganized. Lack of code reviews leads to isolated and complex bugs, weakening software architecture.

“Just don’t write bugs…”

— Every software engineering manager ever.

I’m not advocating for the above quote. We all write bugs. The key is changing how teams perceive the work needed to fix bugs, reducing complexity, and improving interactions about bugs among team members.

Examples

Organization 1: Mobile Developer for Hire

I worked on a small team building mobile apps with high turnover due to a lack of structure. Developers were frustrated by endlessly fixing broken code without checks and balances. The codebase was a giant ball of mud—functions were tightly coupled, state was unmanaged, and a single class managed everything.

I was tasked with fixing a UI bug, while 100+ non-UI bugs affecting measurement accuracy were ignored. After two weeks without progress, I proposed organizing around trunk-based development, implementing code reviews, and refactoring the architecture. This plan took months, but we eventually fixed the controls bug and many others.

Organization 2: Enterprise Data Analysis Software

Enterprise software always seems riddled with bugs. At one organization, a bug titled “Issue with Customer Interactions Populating” required refactoring the state management system. Management thought bugs were easy to fix because the code was already written. It took days to identify the problem and refactor the system, fixing several other data issues along the way.

Despite showing my progress, the manager was frustrated by the time taken. In the end, the codebase improved, but I didn’t receive recognition.

Organization 3: Big Finance

Financial software requires 24/7 uptime. This team believed experienced developers didn’t write bugs, leading to a lack of code reviews and collaboration. Critical bugs caused production rollbacks and hotfixes, wasting time and causing blame.

We proposed requiring two code reviewers per PR to ensure quality. This change boosted code quality and caught bugs early. Pair programming and mentorship improved team health and software quality.

Conclusion

Misconceptions about bugs being easy to fix, less important than UI issues, and the idea that skilled developers don’t write bugs lead to challenges. Recognizing the true complexity of bugs, prioritizing structured code reviews, and fostering better communication can enhance code quality, reduce frustrations, and deliver reliable software solutions.

Please let me know if you want to hear more about my thoughts on development, the software engineering industry, or related topics. Thanks for reading!