There’s Actually 3 Kinds of Tech Debt
There is no solution — only trade offs
Back at it again chronicling the various influences of tech on a group of people and that group of people on tech, I’m here to tell you about tech debt. Now you may have heard the analogy that tech debt is like mortgage debt, something that’s always there and must get paid off, but having no real benefit to paying off immediately (I’m not a financial adviser FYI). That is true for most kinds of tech debt but there is a number of forms of tech debt to which that analogy falls apart. Today, I’ll tell you about 3 types of tech debt, what the underlying trade off was that got us here, and how to go about managing it ranked in urgency & seriousness.
Sacrificing Long Term Developer Velocity
The long term, relatively low interest rate loan.
This tech debt is most closely aligned with the analogy of the mortgage. You’ll see this happen when you’re trying to implement something similar to what exists in the product on a short deadline. This manifests itself as copypasta code, lacking test coverage, or weird abstractions that don’t make sense. There’s a ton of opportunity to refactor the code but not today because the future of the company is riding on this deliverable being done yesterday. All that repeat code is confusing for developers to read, the subtle differences are hard to spot and lead to more ad hoc meetings to understand, and lack of test coverage makes it hard to ensure changes can get made without breaking the app requiring extra TLC to make up for this. Having to reason about bloated & bad code is also bad for developer experience (more on that later). Repay this debt over time by identifying and documenting refactor and test needs, ticketing that work, and committing to a nonzero percent of that work making it into each sprint.
Cutting Scope
The short term, higher interest payday loan.
This form of tech debt is where you do the job less efficiently or in such a way that the problem is solved for a customer but there may be some of manual workaround in place. This is your brute force solution to a leetcode problem or a Mechanical Turk pulling levers behind the scenes while your customer experiences only the promised interface to your product. If you’re in product building a demo, this is also known as the “smoke and mirrors” demo. This tech debt results in a bunch of //todo comments in code to go back and implement the less than pleasant or sub-efficient code paths. Repay this debt as the customer is satisfied with the initial deliverable and is open to a real agile process in which they are part of the journey and patient enough until you close the gap.
Neglecting Developer Experience
Buying that Charger at 27% and never paying the bill.
You got a React Rockstar to build a beautiful app with code and test coverage that requires no hacky workaround out to the customer in time for them to renew your contract — Congrats 🎉. Except nobody put any thought into how anyone else is supposed to work on the app. The test suite takes 30 minutes to run each time, the compiler takes about 10 seconds to run each time a file is saved, spinning up the local environment takes on average 2 hours a week before debugging some esoteric issue with M1 MacBooks and Docker (why is the React app in docker?!?!) and deployment is a complete mystery to anyone who isn’t a cloud enthusiast. This tech debt is nasty because not only does it hinder velocity, the experience for the developer is abysmal and contributes directly to burnout and attrition. Because not solving this problem once means each developer on your team is “solving” this problem multiple times a day wasting hundreds of dev-hours a week, you should repay this tech debt as soon as reasonably applicable depending on how much time is lost per sprint on running the app in the local development configuration.
Wrapping Up
As you can see, some tech debt, if managed responsibly, can exist for the life of the product like mortgage debt. Other tech debt is more akin to preventative maintenance on your car. Sure, you can punt it for a week or two, but completely neglecting it will kill your gas mileage and eventually your engine costing you much more in the long run than the price of doing it up front. Some combinations of tech debt, when unmanaged, ends up costing the equivalent of losing 1–2 headcount depending on the size and scope of your team and the situation (and that’s before burnout-based attrition sets in). While it doesn’t move the needle for the customer today, a sustainable engineering org will make time for making developers’ lives easier while not sacrificing the customer’s experience of your product.
