Hacker News Reader

> I once had a conversation with a "Business Guy" and I brought up the concept of "technical debt." Their response was "Oh! Great! We have lots of cash right now and can add more programmers later to pay down the debt, but only if we release something very, very fast!" -- While the concept of technical debt make sense to me, a software person, the business guy's response was "debt is something that can help you if used strategically." We changed over to using the phrase "Delivery Molasses" because the more of it you got, the harder it was to move through it.

To continue the analogy, perhaps the disagreement was what the interest rate is on technical debt? Or that viewing it as "debt" makes you think throwing money at the problem can fix it quickly, when it has to be paid down through labor instead?

Absolutely. I think the "business guy" was mostly familiar with non-usurous interest rates. They hadn't heard the term "technical debt" enough to understand that interest rates increase the more you borrow. Every bit of cruft you add to the code adds to the interest rate as well as the principal.

Also, the technical loan shark is particularly vicious.

Totally. Guesstimating interest rates for various types of tech debt is a fun exercise:

- Using a single-letter variable: 10% interest on any code which uses that variable. That is, any work involving that variable takes 10% longer than it otherwise would.

- Tests run for long enough to get distracted: 1% interest rate on the production code per second of test runtime. If this calculation could be worked out to anywhere near ballpark accuracy it would be a huge benefit to knowing which language/framework to choose for production/test code.

- Flaky tests: 100% interest on the test code + 10% interest on the code under test, mostly due to having to re-run the entire test suite in CI on an irregular basis.

- Not having tests for a piece of code: 1,000% interest on that code and anything that depends on it. Basically, overall and in the long run I'd expect any work involving untested code to take ~10x the time it would take for well-tested code, due to having to figure out what it's meant to do (explained and proven by good tests), how it does it (generally pulled apart into easily understood parts if it's got a good test suite), and why the changed code doesn't work.

This is obviously not scientific, but it would be cool to have the time to work out what a framework for such calculations would look like, and applying it based on experienced people's estimates.

... unless some code/feature gets deprecated and has to be removed anyways.

But yeah, I think there should be some concrete examples with concrete times to help people to understand better what the impact is. And it should be noted that technical debt is not debt to a single entity. It's like debt to multiple entities. Sometimes technical debt for a certain part MUST be paid back right now, or a critical bug cannot be fixed and a client is lost. You can't buy more time by increasing the interest and paying more later. Not possible.

It also grows scope over time, as more systems are built around it. Which means to fix it, someone needs to learn several systems.

- Tests run for long enough to get distracted: 1% interest rate on the production code per second of test runtime. If this calculation could be worked out to anywhere near ballpark accuracy it would be a huge benefit to knowing which language/framework to choose for production/test code.

I am not sure if I agree with this (or maybe I just don't understand what you mean).

I am working on a large, horribly legacy system (running for 25 years now). When I add/alter some functionality, the time for materially executing a test is < 1sec. The time needed to verify that the result is exactly what I expected can take 15-20 mins. Or balloon into hours if I find something that I do not expect and I need to confirm that the result is the correct one (and I just missed/forgot about the interaction of decades old business rules).

So if had everything rewritten in Assembler, to take your idea to the extreme, the test would take maybe 1/10th or maybe 1/100th to run. And the verification of the results would probably take days of human work to complete.

> The time needed to verify that the result is exactly what I expected can take 15-20 mins.

If the verification isn't automated, you're not running automated tests. So I'd add the 15-20 minutes extra to the test runtime.

I like the idea of interest rate.

I think it often has to actually be paid back in a worse way than money or labor, it often can't be paid back without business disruption, that means slowed future expansion, growth, possible user loss due to bugs, or lack of addressing their future needs and issues promptly, it can come with downtime, feature freezes, etc.

Technical debt is debt in something non-fungible. You don't just need to pay it back, you need to pay it back with exactly the right thing. You can't just get a lump of commodity code and drop it in. That makes it much more expensive to pay back.

It's a bit worse than that. What we call "technical debt" is roughly the equivalent of building a skyscraper with inferior steel and saying we're going to go back and fix it later.

The skyscraper is also a flawed analogy because it doesn't cover the fact that this will somehow magically slow down the work on the rest of the building until it is fixed. The molasses metaphor is good for that one, but I don't see how I can mix the two.

Technical debt is a metaphor that's easy to understand for everybody but it could be the wrong one especially when talking to business people. Try unhedged call options instead as explained in https://www.castsoftware.com/blog/bad-code-isnt-technical-de...

That introduces the concept of risk and of very bad consequences. That should be easy to understand for them. On the other side, does the average person know what's a call option? And an unhedged one?

Technical debt can help you deliver faster.

But it depends on your time horizon. And how much debt you're taking. For most places I've worked, the analogy isn't a cash-flush business, it's a household that's living paycheck to paycheck. The feature requests are insatiable, and there's never enough headcount to pay for them all to get finished as fast as they would like.

If you can only afford is Top Ramen, you probably shouldn't be taking loans out to eat at Maestro's.

> Technical debt can help you deliver faster.

But the interest rate can be worse than a loan shark.

Far too many prototypes make their way into production. I know because I’m maintaining a 10yo legacy product that started as a prototype that should never have made it into production but that is an essential tool for the project and basically un-replaceable. It’s an absolute nightmare to maintain as a result.

I wrote an article recently trying to put across my thoughts that debt isn't actually a very good analogy for maintainable code, basically because it doesn't really fit in with the opportunity cost calculating that real debt has: https://dev.to/aha/technical-debt-isnt-technically-debt-4oke

As someone that also deals with security, what I like is that memory corruption bug fixes and exploits are being mapped into the money spent fixing them.