5 ms·

I like where this is going. Most projects I've been on recently have a "hurry up and get something out" mentality. Which... I'm not completely opposed to. It

I like where this is going. Most projects I've been on recently have a "hurry up and get something out" mentality. Which... I'm not completely opposed to. It's important to get some early design wins out. But the flip side of this is as you go on, you learn more about the problem domain and whether specific solutions are appropriate. You should be okay with throwing out bad code or code that internalizes old requirements that didn't survive into the present. 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. And rather than silently stew about how "business people" don't understand software, putting it in terms they understand so you can have a grown-up conversation is worthwhile. So... happy to see someone's doing that here.

ahepp 4y ago
> 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?
- retrocryptid 4y ago
  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.
  - rbanffy 4y ago
    Also, the technical loan shark is particularly vicious.
- 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.
- didibus 4y ago
  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.
- hgomersall 4y ago
  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.
  - PainfullyNormal 4y ago
    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.
pjmlp 4y ago
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.
deleted 4y ago
[deleted]
bcrosby95 4y ago
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.
- peteradio 4y ago
  > Technical debt can help you deliver faster. But the interest rate can be worse than a loan shark.
pmontra 4y ago
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-debt-its-an-unhedged-call-option 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?
temporallobe 4y ago
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.
jemmyw 4y ago
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 https://dev.to/aha/technical-debt-isnt-technically-debt-4oke

ahepp 4y ago

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

retrocryptid 4y ago
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.
- rbanffy 4y ago
  Also, the technical loan shark is particularly vicious.
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.
didibus 4y ago
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.
hgomersall 4y ago
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.
- PainfullyNormal 4y ago
  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.

pjmlp 4y ago

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.

deleted 4y ago

[deleted]

bcrosby95 4y ago

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.

peteradio 4y ago
> Technical debt can help you deliver faster. But the interest rate can be worse than a loan shark.

pmontra 4y ago

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-debt-its-an-unhedged-call-option 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?

temporallobe 4y ago

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.

jemmyw 4y ago

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 https://dev.to/aha/technical-debt-isnt-technically-debt-4oke