Questions about the debt in tech debt

Tech debt is a term that gets thrown around a lot. It gets used as short hand for a lot of different problems/design decisions/errors/ without people really considering what debt means. Ward Cunningham (who coined the term) describes it as

“I thought that rushing software out the door to get some experience with it was a good idea, but that of course, you would eventually go back and as you learned things about that software you would repay that loan by refactoring the program to reflect your experience as you acquired it.”

video

I like to think of it as with tech debt you’re getting some speed of development now for slow some down later. At its simplest you are trading development time now for development time later. That pretty much defines tech debt as we currently think about it.

But if you know anything about finance you know there are a variety of types of financial debt. Similarly there are lots of different types of technical debt. Normally we only think of tech debt as either slowing us down (this decision means it takes us a few extra hours to roll out the servers every week) or preventing us from doing something later (if we want to scale we’re going to have to go in and change our architecture to switch to micro-services). But the different things we lump together as tech debt have the same variety of features as financial debt. This means we can ask interesting questions about tech debt by framing it as a question about financial debt.

What is securing this tech debt?

When you take out a car loan or a mortgage if you fail to pay your car or house can be repossessed. If you fail to pay this tech debt what product or feature stops working? It is useful to ask this question when you are deciding what tech debt to pay and what tech debt to defer payment on. Tech debt is not fungible. Paying off tech debt in a MVP to open up a new market is not the same as paying off tech debt in your core infrastructure.

Conversely you have more freedom in how you handle tech debt in the MVP than the core product. If the debt in the MVP is too high you have the option of just walking away from the product, or rebuilding it. Just as people walk away from underwater mortgages you should not be afraid to walk away from underwater projects.

Does this technical debt require periodic payments?

Usually this is the type of tech debt that manifests itself as something not being automated. On the Joel Test step 2 is can you make the build in a single step. Not having the build be automated requires dev effort every time you want to build. Similarly part of why Puppet and Chef are popular is that not automating the dev-ops effort of managing servers, especially when they may be making the same change multiple times a day, is a huge waste of resources. Anecdotally it seems anything that happens with a frequency of a fortnight or more gets ‘payed off’ and anything less frequent does not. It would be interesting to look at any technical tasks you do on a monthly basis and see if they are worth automating.

A large portion of tech debt does not require payments, it is only when you want to change something that it costs you. Product managers and tech-leads want to distinguish between debts that require payments and debts that do not.

From a developer perspective even technical debt with out payments is a form of psychic baggage.

Does this technical debt accrue interest?

Technical debt is always harder to pay off the longer you wait. Part of this is simply context switching and the passing of time. It is easier to fix something when it was the last thing you worked on and it was last week versus it was three months and four projects ago. By not paying off technical debt right away the cost goes up because the developer needs to regain familiarity with the problem. The more time that passes the less familiarity the team will have with the code. This interest is cappped at whatever the cost of a completely new person working on it is.

The more insidious interest is that the longer the tech debt remains the more likely another system will start relying on it. The original tech debt ossifies through other features having dependencies on it. Any time you add a feature that indirectly relies on the technical debt you make it more expensive to go back and fix. For example if you are rolling out a new product and your current database schema does not really support the actual data model but can be munged to fit. The product is a success and the business starts pulling data from the old database schema. Now if you want to fix the schema to support the actual data model you need to fix metrics also.

Can we pay it off whenever we want?

If you had two weeks right now could you fix the problem? If your software is installed on users computers you have to work within the release cycle. If you chose to do some preprocessing on the client side and want to move it to the server side you can’t just fix the code, you also need to get it deployed to all those computers.

Similarly if you have an API to support then you can only make changes or deprecate it while coordinating with others. Technical debt on deployed code or APIs has an early repayment fee of either having to support the old system.

Does it have a maturity date?

Will there be a point where you absolutely have to pay off this technical debt no matter what the costs. Normally these are issues of scale. Any sentence that sounds like “This solution won’t work when we have a floppity jillion users” is talking about this type of tech debt. If you make decisions early on that won’t scale and then your products does well then you have to go back in and pay off the tech debt.

If the product never does well enough to scale then you never have to pay off that debt.

Although scaling is probably the most common form of tech debt with a maturity date others do occur. Y2K was a literal date where 30 years of tech debt needed to be paid off by.

These are obviously not all the financial style questions to help think about tech debt, but they are a start. Using the questions of financial debt provides you with some useful tools to think about your tech debt without having to reinvent the entire apparatus. Some other avenues of inquiry that I left out because they deserve their own article:

How is choosing what tech debt to incur and what tech debt not to incur like options trading?

Is there a survivorship bias associated with projects that incur (certain types of) tech debt? Why do most successful projects have tech debt?