Communicating Technical Debt

Most developers have worked in environments where they are unable to pay down technical debt, not due to the technical difficulty of the task, but because of organizational priorities, fears, urgent deadlines, and a lack of clear understanding of the full impact of technical debt on their software.

In this chapter, we’ll explore some of these factors that can prevent you and your team from resolving technical debt and introduce some ways of helping the organization understand and value the refactoring process.

We’re going to cover the following main topics:

• Overcoming barriers to refactoring
• Communicating technical debt
• Prioritizing technical debt
• Getting organizational buy-in

Overcoming barriers to refactoring

When I speak with developers in the technical community, almost everyone has stories of being told that they were not allowed to spend time refactoring their code.

Sometimes this mandate came from upper management and sometimes from product management or someone involved in the agile process. However, just as often, the directive would come from engineering leadership such as a team lead or engineering manager.

The reasons for this can vary by the organization and project you’re working on, but some common reasons include the following:

• There’s an urgent deadline and the team must focus on meeting it
• Refactoring the code isn’t perceived to provide any business value
• The change would be to a risky area of the application with a lot of technical debt and there’s a risk of introducing bugs
• Developers are told “Don’t worry about the quality of the code; this is just a prototype and won...

Communicating technical debt

Explaining technical debt to non-developers can be challenging. Even when management trusts the development team, it is difficult for managers to understand what engineers deal with or how technical debt slows the software engineering process and introduces tremendous quality risks whenever the application is changed.

Technical debt as risk

In the course of my career, I’ve learned that while management has trouble understanding technical debt, there’s something they have a much better understanding of: risk.

This may sound strange, but I’ve found the best way to help management understand technical debt is to present it in terms of risk management.

Every aspect of technical debt in your system has both a probability and an impact.

The probability of a piece of technical debt is the likelihood that the piece of technical debt will impact the development team during development or when the application is running in production...

Prioritizing technical debt

Tracking and communicating technical debt is a critical part of the process of paying it down. However, it’s just one step in the process.

While refactoring code as related code is modified can be a viable strategy for paying down technical debt, this approach isn’t suitable for tackling large pieces of technical debt or debt that is related to the overall design of the software.

In Chapter 17, Agile Refactoring, we’ll talk more about managing these larger pieces of work in an agile environment, but for now, let’s look at how you determine which pieces of technical debt should be prioritized.

You want to prioritize addressing the items that are most likely to occur and those that will hurt the most if they do occur. In other words, if you have a high probability risk, you should prioritize that. Additionally, you should prioritize your high-impact pieces of technical debt.

Calculating risk priorities with a risk score...

Getting organizational buy-in

We’ve seen how we can track and prioritize technical debt, and we’ve seen how involving management in the process of tracking technical risk can help build trust and understanding, but let’s talk about scenarios where development leadership must “pitch” a major refactoring effort to management.

These conversations can be stressful and represent a critical turning point in software projects. In these high-stakes conversations, your goal is to communicate the following things succinctly and respectfully:

• The problem facing the team and its impact if it is not resolved
• The proposed solution (or a set of proposed solutions to consider)
• The cost of the refactoring effort in terms of developer hours
• The timetable of the refactoring effort
• What you’d like management to do

Note that your goal here isn’t to get them to agree to what you are proposing. Your goal is to get them to...

Case study – Cloudy Skies Airlines

As we close the chapter, let’s look at our case study from Cloudy Skies Airlines.

Brian, a lead developer, has been investigating a growing number of problems with the reservation and payment processing part of the application.

These issues, initially thought to be isolated, seem to occur during peak usage times when many customers are trying to book flights or modify their existing flight reservations.

After investigating, Brian and his team discover that the problems are related to the current design and architecture of the system. While the system could handle the old number of users, it is simply not able to adequately scale to handle peak workloads given its current inefficiencies.

Ordinarily, such a system could be scaled out to have multiple servers running in parallel with a load balancer distributing traffic between them (see Figure 15.4):

Figure 15.4 – A load balancer distributing...

Summary

In this chapter, we explored common objections to refactoring code and paying down technical debt and some reasons and remedies for them.

We also talked about communicating technical debt to management, particularly the idea of technical debt being viewed as a risk to the organization’s systems and productivity. We also introduced the idea of using a risk register to track technical debt over time and improve the visibility of technical debt to non-developers.

We closed with a discussion about prioritizing technical debt, getting permission from management for larger refactoring projects, and the importance of trust, communication, and establishing a partnership with management in the remediation effort.

In the next chapter, we’ll explore the value of code standards in terms of minimizing technical debt over time and how to choose an existing standard or build your own.

Questions

1. What obstacles are you currently encountering in getting time to prioritize technical debt?
2. If management understood the problems you’re dealing with, how could they help you with them in terms of time, resources, or organizational support?
3. What can you and your team do to build a collaborative relationship with management going forward?
4. How well does management understand technical debt and its risks?
5. Does it make sense for you to formally track technical debt as risk?

Further reading

You can find more thoughts on technical debt as risk, communication with engineering leadership, and risk management in general at the following URLs:

• Technical Debt as Risk: https://killalldefects.com/2019/12/24/technical-debt-as-risks/
• Escaping the black hole of technical debt: https://www.atlassian.com/agile/software-development/technical-debt
• How to use a technical debt register: https://blog.logrocket.com/product-management/how-to-use-technical-debt-register/
• Communicating with Management About Technical Debt: https://devops.com/communicating-with-management-about-technical-debt/