The Effects of Technical Debt on Morale

The presence of tech debt negatively impacts morale. Managing it positively impacts morale.

This is the latest issue of my newsletter. Each week I cover research, opinion, or practice in the field of developer productivity and experience.

---

This week I read The influence of Technical Debt on developer morale by Terese Besker, Hadi Ghanbari, Antonio Martini, and Jan Bosch. This study looked to understand the effects of technical debt on developers’ morale. 

My summary of the paper 

Before this, few studies had explored the human aspects of technical debt. Researchers had previously suggested that technical debt has a negative influence on developers’ emotions and their morale, however none had empirically investigated this relationship. 

For this study, researchers used interviews and a survey that collected data from software professionals at five different companies.  

Morale is defined here as a “a cognitive, emotional, and motivational stance toward the goals and tasks of a group. It subsumes confidence, optimism, enthusiasm, and loyalty as well as a sense of common purpose.” To study morale, researchers distilled the concept into three dimensions:

• Affective antecedents, which focuses on developers’ moods, feelings, emotions, and attitudes,

• Future/goal antecedents which focuses on the developers’ goals for the future, and 

• Interpersonal antecedents which addresses the relationships and communication between developers. 

Here’s what the study found: 

Tech debt reduces morale

Researchers identified that the presence of technical debt has an influence on developers’ moods and feelings, and a strong influence on developers’ goals. Specifically: 

• Tech debt negatively impacts developers’ self-worth and confidence. Developers may feel less confident about making decisions with the occurrence of tech debt. Additionally, they may be frustrated or fearful when working in areas with large amounts of technical debt.

• Tech debt negatively impacts developers’ sense of progress. If tech debt isn’t focused on, development speed will decrease as adding new features becomes more challenging. 

• Tech debt makes the future unclear since there may be unpredictable issues. 

These second-order themes and their relationships to technical debt are shown in the thematic map below. Gray boxes are those where a clear relationship was not found; black boxes represent relationships identified in this study. 

Managing tech debt increases developer morale

The management of tech debt was found to increase all three dimensions of morale because it is associated with positive personal and interpersonal feedback. It also enables developers to perform their tasks better and improve software quality in the future. 

Based on these results, the researchers propose a model for how their findings interact with each other. They add, “an appropriate level of technical debt management leads to a virtuous cycle for which the right culture and technical debt prevention mechanisms reinforce each other, leading to happier developers.”

Final thoughts 

This study adds to a growing body of evidence supporting the need to prioritize technical debt work. We’ve covered several ways tech debt impacts developers in this newsletter, for example: 

• It wastes time: almost a quarter of developers’ time is wasted due to having technical debt,

• It makes developers unhappy: bad code quality is one of the top causes of developer unhappiness (also, unhappy developers are less productive and write lower quality code, creating a negative cycle),

• It makes developers less productive: code quality has been causally linked to productivity,

• It leads to turnover: developers working in complex areas of code are ten times more likely to leave,

• And now we know that it influences developer morale as well. 

These studies are useful for framing conversations about why teams need to prioritize technical debt investments as part of their regular work. I recently interviewed Mike Fisher, the former CTO at Etsy, and one point of advice he shared was to do “back of the napkin” math to help translate these issues into a language other executives can understand. He said:

“The important thing is to translate the impact of these problems into numbers that everyone can understand. And it doesn't have to be precise; it can be rough math. For example, we’ve done this with deploys: If you can take a deploy from 15 minutes down to 7 minutes, we can see how substantial that is by taking into account the average salary for engineers, how frequently they deploy, and the time saved that could be every week. You can also look at longer-term problems like attrition. If we lose 6 months of productivity every time a developer leaves, we can calculate the impact it would have if we reduced our attrition. These calculations don’t account for other costs like the cost of disrupting flow — but again, it doesn’t have to be precise.” 

---

That’s it for this week! Share your thoughts and feedback anytime by replying to this email.  

If this email was forwarded to you, subscribe here so you don’t miss any future posts: 

-Abi