TL;DR overview
- Sonar's survey data reveals developers spend approximately 30% of their working time on code maintenance tasks—debugging, refactoring, and managing legacy issues—rather than building new features.
- This maintenance burden reduces developer satisfaction and velocity, with a direct impact on team throughput and the ability to deliver innovation at the pace the business requires.
- Technical debt is the primary driver of this maintenance cost: unresolved code issues compound over time, making even simple changes increasingly risky and time-consuming.
- Adopting the quality code methodology significantly reduces this burden by preventing new issues from entering the codebase, gradually shifting developer time from maintenance back to feature development.
The professional open source survey results we published last year highlighted the impressive reach of open source usage among professional developers. We discovered several interesting data points, including that over 90% of professional developers use open source in building their applications. We also discovered that open source maintainers, when paid, will work on the very same things professional developers want more of—including predictable new features and releases, responsive security fixes, and more.
In our latest survey, which we ran in November and December of last year, we set out to answer some of the follow-up questions that arose after we analyzed the earlier results. Nearly 300 developers responded to our survey, which dives deeper into how professional developers use open source today.
Part 1 covered the reasons professional developers use open source. In part 2, we examined concerns they have with open source, such as avoiding vulnerabilities and making safe bets on packages being maintained in the future.
This post focuses on how much time professional developers dedicate to code maintenance and how much of this time is associated with the open source packages they use.
Finding #3: Code maintenance takes 30% of the average developer’s week, and a quarter of that time is related to the open source packages they use
Our survey found that most respondents (70%) spend between 11 percent and 50 percent of their time on code maintenance. For a 40-hour work week, this equates to between 4.4 and 20 hours per week.
When we translate the percentages into weekly hours for all respondents, the average time developers in our survey spend on maintenance is 12 hours per week. This turns out to be slightly lower than the findings in a report from Stripe, which estimated 17.3 hours spent on code maintenance (13.5 hours addressing technical debt and 3.8 hours on bad code).
But it does beg the question, if developers could get some of this code maintenance time back, what else could they do with it?
Bigger teams spend even more time on code maintenance
We examined the data by respondent geography, development team size, and role/title. The results are mostly consistent across these parameters, with one important exception.
The larger the development team, the larger percentage of time respondents dedicate to code maintenance.
We suspect this could be a factor of the age and size of the codebase, with bigger teams typically working with larger and older codebases, which require more maintenance to keep up to date.
Open source contribution to code maintenance
On average, the open source packages professional developers consume contribute 25% of the total code maintenance workload. But this average masks some interesting variance.
A third of developers in our survey spend more than 25% of their code maintenance time on open source components. And for nearly 10% of respondents, the vast majority of their code maintenance work (between 76 and 100%) relates to open source packages.
These percentage splits are consistent across geography, title, and size of development team, which means some other factor may be at work. One possible explanation might be that developers reporting the majority of their code maintenance work is on open source software may work on applications that only use open source components. Or it could be that the task of open source package maintenance where they work is assigned to specific developers, rather than be distributed evenly across the development team.
The most common open source maintenance work is improving, replacing, and keeping up with packages
Survey respondent: "There are times where an open source platform or dependency's developers no longer have the time to contribute to the projects and the teams can dwindle down until there's no longer support from the leaders in that community."
The most time-consuming and common open source maintenance task is moving to a new major version of a framework or library. This is closely followed by adapting to bugs or breaking changes in an updated dependency. Other time consuming maintenance activities include getting a bug addressed or a feature added to a dependency, falling behind / not staying current with a package, and dealing with issues related to an unmaintained dependency. Somewhat surprisingly, responding to security issues in dependencies consumes less time according to our respondents (although the ramifications of security issues when they do happen can be quite severe).
Frequently, these maintenance activities occur together. For instance, a maintenance lapse in one of the hundreds of React dependencies can trigger a number of activities, as the following tweet illustrates.