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.
