While the cartoon is humorous and relevant, it is not the full story either…
Prioritizing Technical Debt as If Time & Money Matters • Adam Tornhill • GOTO 2022
I found this YouTube video to be a fascinating look at Technical Debt, in particular, using tools, measurement, data, and data analysis to identify where to pay down debt, and how much priority to assign it.
In my professional experience, Technical Debt is exceedingly controversial. In most software development cultures, the Technical Debt Status Quo is,
so it can take a lot of tact to convince people to deal with it. However, convincing people to deal with Technical Debt is difficult because it is difficult to describe the philosophy and principles without some measurement and analysis to make things clear and relevant.
Working backwards from my takeaways
Talent Loss
The main difference between active code and legacy code is how many software developers understand the code, know the original problem to be solved, and how the solutions works?
While we would like software developers to be easily replaceable, in practice this is not true, and using data collection and analysis of software repositories, we can actually show the impact of certain developers leaving the project or company.
Consequently, one of the goals of Technical Debt Management and Refactoring is to reduce the impact of key developers leaving.
-
If some key talent is leaving the project or company, this is a good time to pair them with another developer to refactor some key code together.
- This passes on knowledge
- It’s and opportunity to clean up the code and further reduce Technical Debt
-
Before key people leave, refactoring important code reduces the criticality of code, reduces the impact of key people leaving.
I have really oversimplified things there, and strongly recommend watching the video for a better appreciation. But, my purpose was to suggest one kind of strategy for dealing with Status Quo resistance of addressing Technical Debt. Another way of explaining to people the importance and utility of managing Technical Debt.
Multifarious Reasons
However, there are multifarious reasons to manage Technical Debt, and consequently there are multifarious approaches to take convincing the Status Quo to address Technical Debt. A small sample includes…
-
When Technical Debt starts affecting product/service quality, when it negatively impacts customers, partners, staff, etc. then that may become a compelling argument to use with sales managers, marketing and advertising people, and other customer focused people.
-
When Technical Debt starts affecting costs, when it starts undermining profits, then that may become a compelling argument to use with CFO, CTO, CEO, and other executives.
-
When Technical Debt starts affecting retention of software talent, then that may become a compelling argument to use with Talent Acquisition and Retention staff.
-
When Technical Debt can be explained using hard data and data analysis, then it becomes less abstract and more real, where abstract and philosophical arguments are much harder to sell than tangible arguments.