12 Things Worth Knowing About Technical Debt When You’re Dead, Or In Denver, Or Something

In which I mouth off about Technical Debt, broadly to prod my ego which took a pounding recently

Any discussion of Tech Debt inevitably involves disagreement. We’re like bears with a sore heads on that topic; we can often keep the conflict to a gentle growl but often (especially online) someone’s self-control slips and a ferocious nerdrage is unleashed. Rather than pander to our collective inner baby I’m going gloves-off to try and point out some areas where our conversations are often lacking.

Below are some opinions I’ve gathered over the years; they’re not all original.

1. You’re wrong

Tech Debt is heavily context-specific, so there is no one answer. If you think you have teh one twue opinion on Tech Debt, you’re wrong. You’re holding an elephant’s tail; making partially-informed decisions; a stopped clock right twice a day.

Tech Debt has both a cost and a value. These variables aren’t entirely independent, but they are separate, and both vary with context. Any attempt to reason about Tech Debt that doesn’t start from the context of the project is deeply unwise.

2. It’s not a “Bad Thing”

Some developers see no shades of grey in Technical Debt, with too few speaking in its defence. We feel the pain it can cause and boil over, often rationalising it into a mortal sin pushed on us by short-sighted tech-illiterates.

If you see no value in Tech Debt then you simply don’t understand it yet. Which is fine, don’t worry, you’re far from alone. Even a founder I know boasted of a zero-tech-debt development process (I won’t say who, let’s just say he didn’t find his hockey stick).

Just like financial debt, and every other tool since the first sharp rock, it’s a tool you should use carefully to your advantage.

3. You don’t always have to pay it back

According to surveys by Gartner, McKinsey, and Standish, somewhere between 60% and 75% of big tech projects fail. I haven’t seen data for smaller projects, internal tools, web apps, components, etc, but experience says it’s much higher than we’d like it to be.

Similarly the number of startups that fail, or banks that collapse, gives you a depressing baseline for the probablility that, in 5 years time, your company will be a nothing but a paragraph on LinkedIn and some fading corporate swag. Sorry.

Silver lining; that’s a whole lot of debt that simply gets written off.

I’m really keen to get real data on this, but if any given project has a 1 in 4 chance of being active for 5 years (and I think that estimate is optimistic in a lot of contexts) then that drastically changes the aggregate cost of that debt; making it a better gamble.

4. Product maturity effects the value of debt

The value of debt comes from early delivery. Its value is highest when there’s product uncertainty, and lower when you have well understood requirements. That situation can happen in older companies, but in startups it’s the rule rather than exception.

If your company is pre-Product Market Fit then by definition your product is still uncertain, so prioritising things like architecture or scale, which would need to change if requirements change, is hubris. Unless you find that Product Market Fit then everything else is irrelevant. This makes the value of debt in those companies really high.

Companies at this stage also often build and dispose of components rapidly as they adapt, which reduces the aggregate cost of that debt.

5. Teams acclimatise to it

Companies at different stages have different tolerance for debt, and teams acclimatise to that, anchoring on the accepted cost and value of debt. When someone from an SME, corporate, startup, or agency, changes to a different type of business, this anchoring causes disonnance. They have to adapt to their new team’s context or become a problem.

6. Data model debt costs more

My rule of thumb is that the deeper in your stack you take on debt, the harder it is to fix later. This is especially true if it results in data loss, or if you change the way you handle identifiers/uniqueness or relationships. Schemaless databases don’t really help here, because structural changes hurt wherever the change has to be made.

7. Languages and frameworks can be debt too

Language and framework choices can make delivery faster, at the expense of longer term concerns like maintainability, flexibility, or performance constraints, which in my book makes them areas for potential tech debt. For example, I typically work in startups and recently have been using Node.js because you can build quickly, but in my view it comes with both infrastructure debt and language debt.

Keeping Node.js processes stable in production requires careful process management and error handling, and is not an exact science. Javascript as a language also uses dynamic typing, which reduces comprehensibility of your codebase both by humans and by parsers.

9. You can isolate it to reduce knock-on effects

You can isolate some types of tech debt behind an API; eg a library, a micro-service, or a native interface. Choose any encapsulation model you like.

Isolating the debt helps you deliver early without making a mess in the rest of the codebase, e.g. you might design a recommendation API with a simple implementation behind it in order to learn from real-world use of the rest of your app while you get your smart recommendation system running.

10. Tech debt and features are oil and water

Prioritisation is hard at the best of times, but assessing the priority of features takes a whole different skillset to assessing the priority of tech debt. Even if you found someone who could do both, they’d still suffer cognitive load constantly using those extra skills.

One method I’ve found works well is to set aside a fixed time budget for tech debt (e.g. two days a month) and prioritise tech debt within that, so that prioritisation doesn’t need to be made again and again between the two workstreams. Find your own point-of-least-pain, then increase it as the product matures.

11. Debt doesn’t cause burnout

A lot of folks talk about how Tech Debt causes stress and developer burn-out. Not quite true. Stress and burnout aren’t caused by pressure, they’re caused by external pressure that you can’t control.

If you have a tough deadline imposed on you, that’s stressful. If you control your own tough deadline it’s not stressful, it’s exhilarating. Similarly, if you have tech debt forced upon you it’s stressful and saps your energy, but if you make your own debt decisions it’s a different thing entirely.

The important point here is that the debt isn’t what causes the burnout; the burnout is caused by the way a team talks about and manages debt.

12. Tech debt fuels innovation

Since you can use it to increase the value of your product by more than the cost of the debt, calling it “tech debt” only paints the negative part of the picture; a more complete metaphor would be “leverage”.

Younger companies, typically with a higher value of tech debt and a lower cost of tech debt, can use that to add real value more quickly, and stand a better chance of getting to their hockey stick moment.

After all, if they don’t leverage themselves to the hilt someone else will. So not only is it valuable; it’s critical.

Comments welcome. Keep it clean, you animals.

Richard Marr is co-founder and CTO of Applied, a SaaS platform that increases hiring precision and reduces bias. While he talks big, he’s actually full of crap, and rather spuriously claims to have invented A/B testing.