Saying “technical debt” is lazy
Just about every engineer I know, myself included, has at some point said “we need to address technical debt in this sprint” without explaining what they specifically mean. Though the individual is probably correct about the need to address the specific technical issue, they are doing themselves a disservice by using the phrase “technical debt.”
To someone that is not a software engineer, hearing the phrase “technical debt” can be frustrating. For software engineers, technical debt is an umbrella term that references a laundry list of specific tasks. For non technical folks though, that umbrella term seems like one massive, never ending task. When they hear the phrase “technical debt” come up, especially for weeks or months on end, they tend to think “Didn’t we address this already?”
I believe that using the phrase “technical debt” is lazy. Instead of talking about technical debt, I suggest that we as software engineers try a different approach. We should be more concrete with our communication. An engineer that would like to address some legacy technical issue should say “We need to address {specific technical thing} because it impacts the business in {specific way}.”
I’ve recently witnessed the benefit that communicating in this new way affords engineers. In the last few months, Tradesy has done a lot of work around database performance and stability, a large portion of which was rectifying known issues with the existing code base. Before the team embarked on the work, a number of people from the engineering team sat down and wrote out a document outlining what the four biggest legacy issues were and how they represented either a major risk to system uptime, a significant hindrance to team velocity, or an inordinately long load time for end users. The team also outlined how they planned to resolve each problem and the timeline in which they expected to have the resolutions in place.
The document was shared with a number of stakeholders, and the response was overwhelmingly in favor of tackling the outstanding issues, mainly due to everyone agreeing that:
- It’s hard to make money when the site is down
- Development velocity being impacted by solvable problems is silly
- Customers appreciate a snappy website
By shifting how the team talked about technical debt, they were able to help others see the issues not as debt, but instead as opportunities to improve the business.
Helping people who are not software engineers understand the benefits of fixing a legacy technical issue is a huge reason to change how we as engineers talk about technical debt. There’s another reason it’s valuable to rephrase though: the rephrasing forces us as engineers to think critically about the business value of prioritizing the issue. When we are forced to think in this new manner, the technical issues which truly need to be addressed due to their negative impact on the business tend to bubble to the top, and the “nice to haves” are recognized as just that.
Thanks to Jesse and Megan for feedback.
Image courtesy of Dan Simpson https://flic.kr/p/4xxMHh
