Developers' Perspectives on Technical Debt Payment
Lack of time and organizational interest are common reasons for not focusing on technical debt.
This is the latest issue of my newsletter. Each week I cover the latest research and perspectives on developer productivity.
This week I read Software practitioners’ point of view on technical debt payment, a paper by Sávio Freire, Nicolli Rios, and their colleagues that explored how software practitioners handle technical debt, how they pay it off, and why they sometimes don't.
For leaders working to encourage individual teams to drive their own improvements to tech debt, this paper highlights potential obstacles to overcome.
My summary of the paper
In theory, technical debt can be a reasonable investment if there is a plan to manage it. However, in practice, many teams face issues with technical debt, which suggests that the debt was not intentional, lacks a clear definition, or is not considered a significant problem yet. This study investigated the practices teams use to pay down tech debt, and the reasons for not paying it back.
Researchers conducted this study by collecting 653 survey responses from practitioners at different companies about technical debt payment. The survey included both closed and open questions; open questions were iteratively categorized into themes.
Here’s what their analysis found:
The practices developers use to tackle technical debt
Developers were asked to describe a technical debt item that occurred in their project, and then were asked whether that item was paid off. 40% of participants said the technical debt item was paid off. Researchers then asked these participants how the technical debt was paid off.
This revealed 32 strategies for addressing technical debt. The table below lists the 10 most frequently cited strategies:
Not all of the identified strategies result directly in the elimination of tech debt. The practices code refactoring, design refactoring, and adjusting code to follow good programming practices do allow direct payment of technical debt, but developers also follow other practices to enable future tech debt payment (e.g., negotiating a deadline extension), and preventions (e.g., investing effort on testing activities).
Additionally, the researchers categorized all 32 tech debt strategies into themes. These were the top themes that emerged:
Internal quality issues: Practices that can be employed to address limitations that compromise the internal quality of the software, such as code refactoring and design refactoring.
Methodology: Practices associated with processes followed by a software team. For example, investing effort on TD payment activities, investing effort on testing activities, and using short feedback iterations.
Planning and management: Practices associated with management activities, such as monitoring and controlling project activities, prioritizing TD items, and negotiating deadline extension.
Development issues: Practices that are applied during the implementation of software, such as update system documentation, adjusting code to follow good programming practices, and solving technical issues.
The reasons for not paying down technical debt
60% of developers in the survey indicated the technical debt item mentioned was not paid off. Researchers asked these participants to explain why—from this, they identified the top 10 most commonly cited reasons for not paying off technical debt:
There are two types of “reasons” shown in this table: some relate to situations where a team chooses not to address technical debt (e.g., focusing on short-term goals, lack of organizational interest), while others pertain to instances where the team wanted to address it but could not (e.g., lack of time, cost, and lack of resources).
The researchers also categorized the reasons for not paying off technical debt into themes (listed in order of their prevalence):
Planning and management: Reasons related to management activities, such as focusing on short term goals, lack of time, and cost.
Organizational: Reasons associated with organizational decisions. For example, lack of organizational interest, lack of resources, and high team turnover.
External factors: Reasons related to factors that are out of control of the development team, such as customer decision, the project was discontinued, and TD items do not affect the user.
People: Reasons related to team characteristics, such as insufficient management view about TD payment, team overload, and lack of committed team.
Internal quality issues: Reasons related to characteristics of system code and structure, including complexity of the TD item and number of TD items.
Development issues: Reasons related to software development activities: for example, complexity of the project and decision to not change the framework.
Lack of knowledge: Reasons associated with the need for technical knowledge. For example, lack of technical knowledge and lack of knowledge about TD.
Methodology: Reasons associated with process activities, such as lack of adoption of lessons learned, lack of testing, and non-application of mitigation actions on TD causes.
The researchers conducted a follow-on analysis of the relationship between reasons for technical debt and the types of technical debt. They found that payment of all types of tech debt face obstacles from the category planning and management, implying that it is important to involve project managers in tech debt payment initiatives.
Final thoughts
I recently read an article by Atlassian’s CTO that explained their approach to getting individual development teams to drive their own developer experience improvements. He wrote:
We also gave our teams more control over their roadmaps. When we spoke to our dev leads, we found that each team had its own unique blend of issues, but didn’t feel they had permission to spend time fixing them. So my leadership team, along with Atlassian’s co-founders, told our developers to use 10% of their time improving the things that make their day job suck.
This practice is exactly what’s needed for companies to drive local improvements. It’s also a practice I’ve seen some organizations use to drive improvements to technical debt in particular: they’ll allocate “10% time” towards focusing on tech debt, or establish longer initiatives that include hackathons and celebrations.
For other leaders striving to encourage teams to address tech debt, this paper provides insights into the reasons developers don’t follow through. Interestingly, “lack of time,” “cost,” and “lack of organizational interest,” were the most prevalent reasons for developers to not focus on tech debt. This suggests that it would be worth the effort for leaders to spend more time communicating the importance of developers taking time to focus on tech debt, and ensuring they have the time to do so.
That’s it for this week! If you this someone else might enjoy this issue, consider sharing it:
P.S. If you’re interested in more research, send me a connection request with the note “research” and I’ll share a downloadable bundle of my top 10 favorite papers of this year.