4 ms·

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 t

by l0b0 4y ago

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.

valenterry 4y ago
... 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.
- willjp 4y ago
  It also grows scope over time, as more systems are built around it. Which means to fix it, someone needs to learn several systems.
Pamar 4y ago
- 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.
- l0b0 4y ago
  > 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.

by l0b0 4y ago

valenterry 4y ago

... 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.

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

Pamar 4y ago

- 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.

l0b0 4y ago
> 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.