Understanding "Tech Debt"
When engineers tell their managers they need to work on “tech debt”, the result is usually a blank stare back. Working on tech debt doesn’t change anything visible about the product and just takes up engineers’ time, so why does it matter? In this article we’ll go over some of the types of technical debt, and why it’s worth engineers’ time to fix. We’ll also go over cases where technical debt could be a costly distraction.
What is “Tech Debt”?
Tech debt is any behind-the-scenes work that needs to be done to improve the ability of engineers to work in a codebase. This doesn’t add any new features that users can see, but it can make it a lot easier and faster for engineers to add features in the future. The term “debt” is apt because much like financial debt, the longer you don’t pay down the debt the more you need to spend in interest servicing the debt. A little bit of technical debt won’t slow you down much, but if it keeps piling up then it will take longer and longer to make progress in a codebase.
You can imagine being a chef working in a kitchen. At first the kitchen is spotless and everything is where you expect it to be. However, As orders come in the kitchen becomes a mess. You need to spend time rummaging for the knife and pan that you need, and you need to move piles of half-clean pots and pans out of the way. This mess that builds up is technical debt. Like in a kitchen, it’s worth it to spend time cleaning up to make sure you can keep operating at maximum efficiency.
Leaving tech debt unfixed means your team will not be able to ship features as efficiently as possible. Often the debt will need to be paid down at some point, but the longer you wait to pay it down the more productivity gets lost in the meantime, so it’s important to track debt and spend time proactively dealing with it.
Below, we’ll look at some of the common ways technical debt can accumulate, and some ways to deal with it.
Software that’s being worked on actively by lots of engineers will naturally start degrading in quality over time. People come in and fix one small part of the system, then someone tweaks something else, and so on. The code wasn’t intentionally designed to be the way it is - it’s just slowly evolved as minor changes have piled up, and now the code design just doesn’t make much sense. This requires constant effort by engineers to correct for, either by just taking some time every few months to clean up code that’s started to drift in quality, or by actively fixing up nearby code as they work. Software rot is a slowly creeping form of technical debt - it makes the code more and more difficult to work with over time, but it usually doesn’t break anything all at once.
Sometimes the design of a part of the system is just not able to deliver on what’s required. This could either be because the system was just not well designed, or, more likely, the requirements have changed over time and now the architecture can’t do what’s needed. This sort of debt typically needs to be addressed before a new feature can be added, so it can’t be ignored.
You can think of this like working in a kitchen that only has a stove. This is fine as long as your restaurant only serves stir-fry and scrambled eggs. But, if your boss comes in and says you need to start making pizza, then your kitchen isn’t going to cut it. You’ll need to take some time to shut the kitchen down and renovate it to install an oven. This sort of situation is analogous to architecture debt - you need to stop what you’re doing and address the issue before you’re able to add the feature.
Sometimes engineers can hack around the issue with architecture debt, but it’s never ideal. For instance, at one place I worked we didn’t have an error tracking system in place, so we just had our servers send us emails whenever an error occurred. One day we overloaded the entire company’s email inbox when we had a particularly bad error and none of us could receive emails for a week. At that point we had to stop and implement a proper error tracking solution. In the kitchen example, maybe you can try putting the pizza in a metal box on top of the stove to simulate an oven to avoid needing the renovation right now. But, eventually, the hacky solutions aren’t going to cut it and you’re going to need to just do the renovation
Sometimes engineers cut corners intentionally to get things done. This can be due to laziness, but usually it’s done to get a feature shipped sooner. Things that get cut are usually things that are important for the long-term maintainability of the system, like writing documentation, or adding test coverage. Sometimes the code that’s shipped is just poorly written so it’s difficult to work with, but the engineer doesn’t have time to clean it up. Accumulating this sort of debt can be a good decision if there’s a tight deadline, but only if there’s time allocated to cleaning it up later once the deadline has passed.
When Fixing Tech Debt Goes Wrong
There are times when working on tech debt can go wrong, and probably the most famous example is the code rewrite trap. When tech debt gets too out of control, or when engineers inherit a codebase they don’t understand, there’s a natural reaction to just rewrite it all from scratch. This seems like a sensible thing to do, but it almost never works out. Everyone underestimates how much time and effort it will take to rewrite, and it’s common for these rewrites to take years longer than expected, if they even finish at all. If engineers suggest they need to do a full rewrite of the product, be extremely wary!
The biggest mistake that managers make with regards to tech debt is not prioritizing it at all. Managers typically won’t ever propose working on things that will have no visible impact to the product, and often aren’t aware that there is tech debt that exists that may be holding back their team. The best way to address this is to explicitly put working on tech debt into engineering planning. Managers should sit down with engineers to figure out where there’s debt in the system that needs addressing, and make sure engineers are allowed time to tackle it. This should happen regularly, so that the debt in the codebase never gets out of control.
If you’re not an engineer, hopefully this article gave you some understanding about what engineers mean when they talk about needing to work on tech debt. It’s worth it to work with your engineering team to make sure they’re empowered to spend time cleaning up tech debt on a regular basis. Just be wary of the infamous code rewrite trap that engineers can sometimes fall into. Clean up tech debt regularly, and your engineering team will continue to hum like a well-oiled machine!