Hacker News Reader

Comment by ahepp | 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?

View on HN

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.

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.

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.

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.

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.

Reply on news.ycombinator.com