RDEL #96: What’s the relationship between developer seniority and code refactoring?
Experience level shapes the most likely contributors to refactoring, and may also influence quality of documentation.
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.
Refactoring is critical to long-term code health—but who actually does it may not be as balanced as we think. This week we ask: What’s the relationship between developer seniority and code refactoring?
The context
Refactoring is one of the most trusted tools for improving code quality and managing technical debt. But despite its importance, it often happens quietly—It rarely comes with dedicated time, and often happens “behind the scenes” during feature work or bug fixes. Unlike new features or bug fixes, refactoring doesn’t always have a clear owner or deadline.
While it’s commonly assumed that refactoring is a shared responsibility, prior research suggests otherwise. Studies have hinted that a small subset of experienced developers may be disproportionately responsible for this work. Understanding how refactoring activity maps to developer experience—who performs it, when, and why—is essential for building more maintainable systems and more intentional team practices.
The research
To understand the connection between developer experience and refactoring behavior, researchers studied 800 open-source Java projects hosted on GitHub. They mined over 700,000 refactoring operations across 111,884 commits, and analyzed developer contribution levels using a metric called Developer Commit Ratio (DCR). They also built a machine learning model to classify the motivation behind each refactoring and assessed how documentation practices varied by experience level.
Key findings:
Developers with higher contribution scores performed significantly more refactorings.
Top 5% of contributors (by seniority) averaged 11.14 refactorings, compared to 3.57 for everyone else.
These top contributors often held advanced roles like tech lead or senior engineer.
Refactoring motivations went beyond code smells and design hygiene.
Only a minority of refactorings were motivated by code quality issues like code smells. The most common motivations were feature implementation and bug fixes, not internal design improvements. There was no correlation between experience and motivation behind refactoring.
Experienced developers performed a wider variety of refactorings.
The most senior developers applied a more diverse set of refactorings across all categories—bug fixes, features, internal quality, and more—compared to less experienced developers.
More experienced developers documented refactoring less often.
The most senior developers documented refactoring tasks less than less experienced developers. Conversely, less experienced developers were more likely to write verbose commit messages.
The application
This research highlights a clear trend: refactoring is essential work, but it’s not evenly distributed. It’s typically carried by a small group of experienced developers—those with enough context, trust, and ownership to reshape core systems.
For engineering leaders who want to take this research into practice, consider the following ideas:
Make refactoring a visible, team-wide practice.
Ensure all developers—especially early-career ones—are encouraged and supported to refactor. Pairing, review checklists, and shared design principles can lower the barrier.
Recognize and reward “invisible work.”
Refactoring often lacks the visibility of features or bug fixes. Acknowledge it in retros, promotion criteria, and goal-setting to signal its value to the team.
Invest in documentation, regardless of seniority.
The entire team benefits from clearer commit messages and some context on the work being done. Consider lightweight prompts or review checklists that reinforce the importance of documenting structural changes.
—
Happy Research Tuesday!
Lizzie