Technical debt is a frequent topic we cover with clients. Technology products are never ‘done'. The art of keeping a platform optimized for product outcomes is a journey. Balancing expanding customer needs and the technologies available can be hard.
We have written about this topic before but based on recent experience we felt the need to expand the discussion. There are a lot of aspects of keeping a platform healthy on an ongoing basis. We need to be specific about the type of work needed to keep an application running well and evolving over time.
We have created a series of posts on all aspects of application health and maintenance. Some of these items are correctly classified as tech debt. Others are often incorrectly labeled under the tech debt umbrella. Nonetheless are of these items are critical to application health.
This first post updates the definition of Tech Debt. It is a foundation for later posts in the series. This series will focus on the categories of work that are part of the Application Ongoing Health and Maintenance category of engineering effort.
Technical Debt as a Metaphor
Technical debt is a phrase coined by Ward Cunningham in 1992. It’s a metaphor. Metaphors are great because they can help bridge a knowledge gap by making complex thoughts easier to understand. If you are explaining something to me that I don’t understand you use a metaphor. Metaphors are based on subjects we both have in common that bridges the knowledge gap. This creates a common scaffolding we can both hang ideas on to better communicate.
Technical debt started out as a good metaphor. Anyone who has hung around an 8-year-old knows that metaphors can be pushed too far. Technical debt is a metaphor that has been pushed a little far. Let’s reset the metaphor and take it back to its roots.
What Technical Debt Is NOT
Sometimes the best way to understand technical debt is to understand what is NOT technical debt. There has been some confusion around this so I am going to say this slowly,
Technical debt != poorly written code
Technical debt != bugs
Technical debt != bad decisions made by the last guy
Just like when you used your student loans to go on a bender in Sao Paolo is not “student loan debt”. You might classify it as student loan debt but we all know you weren’t there furthering your education. Cruft needs to be identified and fixed but it should not be categorized with technical debt. Technical debt is not a bad decision or a mistake, technical debt is strategic.
These other categories of non-tech debt that also need to be addressed are discussed in later posts.
What is Technical Debt
When you go to the bank to get a loan, one of the first things they ask you is “what are you going to use the loan for?” If your answer is, “I am taking your money to Vegas and placing it all on black 4,” you will be quietly ushered out of the bank.
Like any real-world debt, technical debt has to have a legitimate purpose. Technical debt is a conscious choice you make to help speed up development. You build something a certain way, knowing you will most likely need to change it in the future.
Technical debt should be deliberate and prudent. You plan on taking on the debt for a known cost with a known benefit. This isn't a payday loan for the craps table. This is debt that deliberate and understood by all parties involved in the decision.
The Dangers of Technical Debt
Like any form of debt, there are consequences for leaving it unpaid. In the software world this means that every time a future developer touches that codebase, their velocity will drop. The loss of velocity is the "interest" you pay for technical debt.
The longer you take to refactor the debt, the more it costs the business in lost time.
What To Do About Technical Debt
Agree on repaying your technical debt
When the business asks you to take a shortcut for to ship a feature quicker, they need to be part of the contract. They need to understand that the debt will have to be paid and that means less development time in a future sprint. When you go back and tell them in a later sprint that you need time to refactor they need to remember this agreement.
Too many times technical debt isn't understood by the business and isn't communicated by the development team. All parties need to take on this debt together in a deliberate manner. It's the entire product team's debt.
Track your technical debt
The most common problem companies have with technical debt is that they forget about it and move on. You can't pay back a debt you don't remember. Document every time you take on technical debt. If you aren't tracking it then you will get busy with new feature development and forget about it. The business will take all the capacity you are able to give them.
It is important that you track your technical debt. The easiest way is to add it back to the backlog and tag it as debt.
Always be paying back the debt
The only way to keep technical debt from growing into a monster is to constantly be paying it back. A part of every sprint should be dedicated to paying down this debt. This is the car maintenance required to keep a formula one car running its best. A certain amount of the team's capacity has to be dedicated to ensuring the team's future velocity isn't hijacked.
How much you dedicate to refactoring technical debt depends on where you are as a company. Software companies that have ignored the debt for years might need to put aside 40% of all engineering time towards it. More than likely you can get away with 10-20% of your time paying it back.
Encourage your engineers to embrace the Boy Scout Rule of software. Always leave your codebase cleaner than you found it. This doesn't have to be a major effort. Change a poorly named variable. Reduce duplication. Anytime you see that a piece of code isn't as clear as it should be, show it some love. You'll thank yourself next time you have to touch that code. Cleaner code helps us ship faster.
Final Thoughts
Technical debt can be a double-edged sword. Like all business debt, when used correctly it can be a valuable tool for the business to accelerate growth. If you leave that debt in your codebase for too long, you will lose the advantage of taking the shortcut. Agree on the debt, track the debt, and pay it back on time.