RDEL #82: How do developers fix bugs differently when they don't author them?
Over half of bugs fixed are from a different developer, and bugs fixed by other developers take a median of 148 days to resolve. We relate the findings to how engineers fix LLM-generated code.
Welcome back to Research-Driven Engineering Leadership. Each week, we pose an interesting topic in engineering leadership and apply the latest research in the field to drive to an answer.
Bug fixing is a natural part of the software development process. In fast-moving teams, engineers frequently fix bugs in code they didn’t write. This week we ask: How does the original author’s involvement impact the speed, scope, and quality of bug fixes?
The context
In any engineering team, bugs are inevitable—but who fixes them can significantly impact both speed and quality. In large-scale software development, engineers often fix issues in code they didn’t write, whether due to team transitions, open-source contributions, or shared code ownership. At the same time, original developers may have critical context that allows them to resolve issues quickly but potentially with a different approach than someone coming in fresh.
This raises an important question: do developers fix their own bugs differently than they fix someone else’s? If original authors resolve issues faster but embed them in broader changes, while non-authors take longer but apply more focused fixes, it could have implications for how teams assign, prioritize, and review bug fixes. Understanding these patterns can help engineering leaders improve debugging workflows and optimize for both efficiency and maintainability.
The research
Researchers at the University of Waterloo studied how the authorship of bug-introducing code affects bug-fixing behaviors for software engineers. Researchers examined 10,231 bug fixes from 100 Java Maven projects, analyzing differences between bug fixes made by the original developer versus a different developer. The researchers tracked bug fix frequency, time to fix, and commit size to uncover key differences in bug-fixing behavior.
Key Findings:
44.3% of simple bugs were fixed by a different developer.
Developers fix their own bugs much faster—within a median of less than one day—whereas fixes by other developers take a median of 148 days.
This massive difference suggests that original developers likely recognize and resolve their mistakes quickly (and often before it hits production), while bugs resolved by other engineers have made it into production and require more time to triage, understand, and fix the issue.
Bug fixes by the original developer are larger and broader in scope, while those by other developers are smaller and more targeted.
The interquartile range (IQR) for bug-fixing commit sizes by original developers was 734 lines of code (LOC), whereas for non-authors, it was only 13 LOC.
This suggests that original developers may take the opportunity to make additional improvements when fixing their own bugs, whereas others focus solely on the specific issue.
The application
As AI-assisted coding becomes more prevalent, the findings from this study offer important parallels. Just as developers take longer to fix bugs in code they didn’t write, teams adopting AI-generated code may face similar challenges. AI-written code can accelerate development, but when errors emerge, debugging takes longer due to the lack of human context. If AI acts as a "non-author" in the coding process, then teams must anticipate longer resolution times and consider strategies to reduce friction when debugging AI-generated code.
To apply this paper to your engineering teams, consider the following ideas:
Shift Left on Testing to Catch Bugs Earlier: since non-author bug fixes take significantly longer, proactive testing can catch bugs before they hit production and reduce the impact on customers. Investing in automated tests, linters, and static analysis tools can help catch issues before they reach production, minimizing the need for complex, time-consuming fixes later.
Improve Knowledge Sharing to Speed Up Debugging: When developers fix someone else’s bug—or debug AI-generated code—they need better ways to ramp up quickly. Encouraging clear documentation, inline comments, and AI-generated explanations can help engineers understand unfamiliar code faster. AI-assisted coding should be paired with strategies that ensure developers can efficiently debug and maintain AI-generated solutions.
By applying these strategies, engineering leaders can mitigate the challenges of debugging both human- and AI-written code, ensuring teams maintain speed and quality as AI becomes an integral part of software development.
—
Happy Research Tuesday,
Lizzie