Tech Debt started out as a useful metaphor. You 'borrow' from the future to achieve an outcome today. Much in the same way you can achieve home ownership earlier by taking out a mortgage after saving enough for a down payment. However, the way it's used now is long past its usefulness as an explanation for anything.

Why is this seemingly simple feature estimated to take so long?
Tech Debt

Why do we keep having incidents with the framajama service?
Tech Debt

How come we failed the security audit again?
Tech Debt

You might as well blame the phase of the moon. It's about as edifying. You wouldn't tell the doctor your problem is "pain" without giving more details, yet I hear 'tech debt' as the entire explanation way too often.

Breaking Down the Concept

Part of your job as a leader is to make technical problems understandable by non-technical stakeholders. Analogies can serve you well here:

• We hung up a sheet of plastic instead of a door when we built the garage so we could start parking the car inside. We need to install the door now.
• We need to change the oil on the car now so the engine doesn't seize later.
• We should patch the leaky basement so that we don't need to deal with the foundation collapsing.

I've said it before, but at its core, management is the art of efficiently deploying capital for the highest return on investment. In a software company most of that capital is in the form of engineering time. To make the best decisions we need to be more precise than just saying we want to use it to "pay down tech debt". That doesn't sell because it is a statement devoid of useful information. It doesn't say anything about what kind of return on investment you might be getting. While specifically quantifying the ROI of preventative maintenance or restorative work in pure dollar terms can be hard or even impossible, using an analogy that most people understand can help make your case.

First things first, you need to understand what kind of debt you're dealing with.

Intentional Debt

When you're talking about intentional tech debt, the shortcuts you took to get a product out the door, talk about the debt in concrete terms. Discuss the specific shortcuts you took and what the 'interest payments' are on them. For example:

• "We shipped this in June to get fast customer feedback knowing it would need to be hardened before Black Friday in November. We need to make these specific improvements before then or we won't make it through the holidays without major downtime."
• "We knew this code wasn't optimized and we deployed it on bigger servers to make up for it. If we spend a couple weeks on performance improvements we can save X thousand dollars over the next year by redeploying it on smaller, less expensive machines."

This is the kind of debt you sometimes should take on but when you're deliberate about it and clear about why you're doing it and what you get out of it, you can also be clear about what's needed to pay it off and what the costs of not doing so are. You can even do all of that without saying the words "technical debt", which is becoming a term that makes people stop listening.

This kind of debt doesn't really need metaphors to explain, as long as you're clear about what the trade-offs and ongoing costs are.

Unintentional Debt

This is probably the most common form and it's where the debt metaphor is often the least useful. You can build the best system you possibly could with the information available and the world can change in ways that your previously well-designed system simply can't handle.

• Your traffic or account sizes could vastly exceed your expectations.
• A library, component, or framework you depended on can become abandoned.
• You made a trade off without realizing it.
• You didn't fully know what you were doing when you wrote it in the first place.

Many seemingly good decisions can prove to have been the wrong one in retrospect. This has a lot of the same characteristics as deliberate debt. You've got ongoing costs related to previous decisions where a project to 'pay down' the debt would remedy the situation. However because it was not taken on deliberately it can be harder to nail down the source of the pain and make a clear case for the remedy. This is especially true when the decisions were in the long ago past and nobody knows or remembers why they were made. To make matters worse, when there's a lot of it it can just sort of feel like a "big blob of yuck" This is the kind of situation that leads to people saying "we should just rewrite it" (Don't).

Now, the inability to clearly articulate the problem can be a problem in and of itself. It's entirely possible that the understanding of the full shape of the system is lacking to the point where nobody can effectively diagnose things in specific enough terms to be useful. This is common in high-turnover organizations or ones that never developed good habits of documenting their decisions. Whatever the cause, it should go on your list of things to remedy.

When you've got these kinds of problems, the age old technique of elephant-eating (one bite at a time) is the solution. Try to categorize, break down, and understand in more detail the types of problems you have. If you must stick with the debt metaphor you can categorize it by 'interest rate':

• Payday Loan Debt (emergency): This is the stuff that's hurting you daily and costing you the most. You're coping, not solving anything. Pay it off ASAP.
• Credit Card Debt (not good): This stuff is a major drag on velocity and there's a clear case to be made for paying it off. Make that case, focus on the ROI.
• Mortgage debt (might be ok): This stuff might or might not have a business case for paying it off. It might bug you a little but it might be worth putting up with. But only by understanding it can you make that call.

Doing this breakdown and classification is probably best done as a group effort. One person's payday loan might be another person's mortgage debt. It's best to understand it in the broadest business context you can and try to be as scientific as you can be. There's bound to be some subjectivity to it and biases and preferences can skew the perception of how bad a problem truly is. Many eyes make this kind of planning more effective.

Neglect

If your product is built on a framework that's still maintained, and the version you're on is going end-of-life because you haven't kept up, that's not tech debt. You've neglected basic maintenance. If your porch is falling apart because the stain protecting the wood has been gone for years and water is rotting the boards that's not increasing the size of your mortgage. If it is debt, it's money you borrowed from the mafia and now they're on their way to break your legs.

As the saying goes, code doesn't age like wine, it ages like milk. With that comes risks that need to be managed. There is often pressure to ignore those risks in favour of new features or other, more exciting things. Who wouldn't rather buy a new flashy electronic gadget than paint the porch again? You know that's irresponsible and so is neglecting basic maintenance of your software systems.

This is one of the reasons it's critically important to align the incentives of the EM and PM partners. If only the EM has the incentive to keep the porch in good shape and only the PM has the incentive to buy new toys, you're gonna have a bad time.

The best way to deal with this type of problem is to not get into it in the first place. The 'good news' is that if you leave it long enough the problem will become so obvious that you won't have to justify fixing it. The bad news is that the fix is going to be way more expensive than if you'd done the basic maintenance that could have prevented it. Don't borrow money from loan sharks!

Our Responsibility

As engineering leaders, we have the responsibility to frame the necessity to do maintenance work and to pay down both deliberate and unintentional technical debt in business terms. Often the problem is that nobody is able to do that successfully until it becomes a crisis.

Taking on deliberate debt with a full understanding and plan to pay it off can get you the software company equivalent of home ownership sooner with manageable interest payments.

Being able to make business case for 'engineering work' or things that aren't just new features is a critical skill for engineering leaders to develop. And whenever you can, make sure your Product counterpart shares both the pain and the glory of having a well-functioning product.

Once y0u develop that skill, you can use it to avoid taking on those payday loans with the highest interest payments and spend your capital on what's best for the business without saddling your future self or your successor with big bills.

"Debt Consolidation, Circa 1948" by Orin Zebest is licensed under CC BY 2.0 .