RDEL #31: How do developers fix their own bugs differently from other developers bugs?
This week we consider the bug fixing patterns of software engineers when resolving their own bugs vs another engineer's bug.
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.
🪲 No matter how much rigor a team has, bugs are an inevitable part of the software development process. This week we look at how developers fix bugs, but specifically: how do patterns change when developers are fixing their own bugs, vs someone else’s bugs?
The context
Bugs, or problems in the code that cause software to not work as intended, are omnipresent in the software development process. They can sometimes be identified during local development and testing, but often are found only after software has been deployed to production. To address bugs, software development teams will triage their urgency and choose to either resolve them immediately or prioritize it at a later time.
Depending on how a bug is discovered, different teammates might be involved in the implementation of the solution. For example, when a bug is both created and discovered in local development, the engineer who introduced that bug can resolve it within their same workstream. When bugs are found in production, it is less likely that the engineer that introduced that bug will be resolving it too.
The research
Researchers at the University of Waterloo studied how the authorship of bug-introducing code affects bug-fixing behaviors for software engineers. To do so, they looked at the SStuBs dataset, a collection of single-statement bug fix changes across the top 100 Maven projects. Using the ever-popular git blame on every project from the top 100 Java Maven projects, they collected and analyzed 10,231 bug fixes to determine who authored vs fixed a bug.
Researchers found that:
44.3% of bugs are fixed by a different developer than the author of the bug
Simple bug fixes by different authors can take a median of 148 days, versus bug fixes by the same author which take a median of under 1 day
Researchers speculate that the massive difference could be due to the fact that many bug fixes from original developers are part of the standard development process. As well, this is a series of open-source projects, so fixes by different authors may take longer due to the volunteer nature of open source projects.
Simple bug fixes by different authors are smaller in lines of code (median of 6) vs in same authors (median of 14).
Researchers again speculate that same-author bug fixes are sometimes part of the standard development process.
The application
This paper offers an interesting view into how developers fix their own bugs versus other developers bugs. The most important takeaway from this paper is that bugs are much easier to resolve when they are caught and addressed early in the development process.
For engineering teams that want to minimize the impact of bugs on their team, the best action they can take is to shift left on testing and make testing a part of the local development process. Bugs that are found in development get resolved much faster than bugs that are found in production. The impact is also markedly different, as bugs in production can impact user experience in small or massive ways. Make sure the team has a process set forth for testing their features, whether its through test-driven development (TDD) or something more lightweight.
—
Wishing you a great, bug free week 🪲. And as always, Happy Research Monday!
Lizzie
From the Quotient team