[1_800_UNICORN]

For the last 5 years I've worked primarily with startup CTOs and enterprise directors/VPs to build teams practices XP, lean product development, and user-centered design.

My advice to them, and my philosophy on this topic, is that technical debt is just that- debt. It's not a dirty four-letter word to be avoided, it's something to be managed the way you manage actual financial debt. There are some projects where the software you build will be self-contained (no dependencies), will require minimal changes in the future, or it may have a short shelf life (e.g. it's a stopgap before you cut over to a new system). In these scenarios, accruing technical debt isn't the worst thing in the world if it allows you to reap business value faster.

When you're building software that's going to live long-term, or that drives core parts of your business (and therefore will need to change frequently as your business changes), technical debt needs to be tackled early and often. It's ok to accrue technical debt in the short term ONLY if you make that decision consciously knowing that you'll need to address it later (e.g. I had a client that needed to release their software for a trade show, so we accrued tech debt and created tasks to track every piece of debt we'd want to tackle later, and then prioritized that work immediately after the trade show).

That said, it's also important to be clear about what constitutes tech debt vs what is over-optimization. Outside of libraries and frameworks, I don't really need the software to be "perfect". I need it to be clear enough, tested thoroughly enough, and easy enough to change to maintain a high velocity. If a part of the code has become spaghetti-like, or if we see code duplicated more than 3 times, or if we have disparate code that's too closely coupled to easily make changes, that's technical debt worth tackling.

The vast majority of organizations I've worked with typically think much shorter term, which is why they find themselves repeatedly accruing technical debt to the point where changes to the system occur at a snail's pace. It takes a lot of discipline, and coordination between IT and business, to practice what I'm describing, but that's the ideal that I strive for and advise my clients to strive for.

[lkrubner]

"It's not a dirty four-letter word to be avoided, it's something to be managed the way you manage actual financial debt."

As others have pointed out, technical debt operates the same way an unhedged option works. It can go catastrophically debt. Compare that to issuing bonds. If you issue $10 million in bonds, you know exactly how much you will have to repay, and you know the interest, and you know when you will have to repay it. With technical debt, you don't know when you'll have to repay it, and you don't know how much it'll cost you. You just go along knowing that someday something catastrophic might happen. See this previous discussion:

https://news.ycombinator.com/item?id=8777237

[waterlink]

Technical debt is very similar to financial debt.

Don’t get fooled. There is very small, and very important difference:

With financial debt, the business takes on it in hopes of delivering more value quicker that will pay for interest and principal, and have a lot of (monetary) value left after.

Financial debt, if anything, is speeding the process of delivery of value up.

On the other hand, technical debt is slowing the delivery down. And this delivery is what business hopes to speed up.

Well, maybe it makes this one iteration/release quicker, but it slows down the next one, and next one after that, and so on.

So, it seems that they are deceivingly similar, but you need to adapt the tactics and strategies.

[smu]

I fail to see the difference. Financial debt is also a brake on future activities, in the sense that you have to pay back with interest, so less funds are available for other activities.

So in your words: it makes this one iteration quicker, but slows down the next one...

[waterlink]

I see what you mean, and I agree partially.

Follow my thoughts (and please do poke holes in them!):

Financial debt allows you to deliver more -> sell more -> pay down debt quicker -> deliver more (if you got it right and haven’t failed).

So the money itself becomes a mechanism by which you deliver faster, and, as a result of faster delivery, earn more money to deliver even more and faster.

Now, the technical debt.

Earning more money from more feature delivered in current iteration might result in more revenue NOW. But does it result in more/faster delivery after that revenue happened?

Not really.

You can potentially hire more people. But they will only slow the team down at first. There is a delay between “more people” => “faster delivery.”

So financial debt can enable a positive reinforcing loop. Can technical debt do that?

[pmarreck]

Technical debt (like financial debt) DOES NOT slow the delivery down AT FIRST. That is why people incur it! It is pure "GSD" (Getting Shit Done) now, make it clean later.

Financial debt "slows profitability down" later. Technical debt "slows productivity down" later. Both affect company profit. LATER. But arguably increase it NOW.

The analogy is in fact apt.

[nichochar]

I personally don't like the term debt. It's a simple analogy but it doesn't go very far.

The biggest issue by far around tech debt, which has been covered thoroughly throughout this thread, is that measuring it is tricky.

Measuring financial debt is trivial, you can put a dollar amount on it. Measuring tech debt is very subjective, as it depends on the level of seniority of your team, their ability/authorization to make changes (in banking, you can change nothing, in a startup, you can change everything), attrition rate, etc...

It's such a complicated equation, that using the term debt tricks upper management (non technical) to think it's easy to predict: it really isn't at all.