3 ms·

I hear lots of folks rant about the term. However, if anyone asked me, I would say that you need to think closely about the word "Debt". Debt powers our econo

I hear lots of folks rant about the term. However, if anyone asked me, I would say that you need to think closely about the word "Debt". Debt powers our economy - from bonds, to Mortgages, to student loans. Debt makes the world go around - it's a decision to pay more money later to get something done now. Tech debt is the same thing - once you just realize how amazing it is, e.g "you want tech debt because it makes something happen now" then this is a positive term, not a negative term. So I say strongly - use the term. Don't let it be a synonym for bad engineering, but for choices.

pydry 4y ago
I think the ranting is indirectly about the lack of any meaningful unit of account. Financial debt would be just as much of a mess if you couldn't count it. Somehow people think that if only we could explain what it was to people who don't get it the problem would be solved. Nope, just need to be able to measure it and stick a price on it (even if it's not much better than a guess) and let it be put it in a spreadsheet with all the other liabilities. The perpetual attempts at redefinition "so they get it", on the other hand, are all gonna get ignored.
- Verdex 4y ago
  I think this is important. There's no real way to measure technical debt. The best we seem to have is cyclomatic complexity and lines of code. Not exactly what I would hope for. Alternatively we have 'best practices' (ie someone with an important title somewhere wrote a blog post about it) and 'code smells' (so ... the code makes your tummy feel bad when you look at it, yeah I'm sure that's objective). There are a few corners of the web where people have been trying things, but I don't know if I'm convinced. It is however better than nothing. https://www.sonarsource.com/docs/CognitiveComplexity.pdf https://www.sonarsource.com/docs/CognitiveComplexity.pdf https://www.progsbase.com/blog/flow-charts-of-programming-language-constructs/ https://www.progsbase.com/blog/flow-charts-of-programming-la... I don't think our industry is going to make any headway into a healthy way to deal with technical debt until we can talk objectively about the coding constructs that we're building. There's too many situations where people are conflating familiarity with objective quality. And even when you get past that the politics of having your coding philosophy win out means you can't trust enough people to honestly approach the issue. EDIT: Additionally, you have to worry about the external politics involved. If vendor A says the feature takes 3 months, but vendor B does the feature in 3 weeks, then it it's pretty clear who the customer is going to want to go with. That is until three days after launch when the module vendor B wrote keeps formatting end users' hard drives. OR MAYBE vendor A are just really bad at their jobs and their 3 month version would be the one formatting hard drives. Those who want software written do not have good metrics for how hard anything actually is.
  - Volundr 4y ago
    > If vendor A says the feature takes 3 months, but vendor B does the feature in 3 weeks, then it it's pretty clear who the customer is going to want to go with. That is until three days after launch when the module vendor B wrote keeps formatting end users' hard drives. Man, I wish this didn't resonate. I once worked as the lead at a company that decided they wanted to build a mobile app. This wasn't something I or the team had done before, but after researching and considering the features I gave an estimate of 6 months for us to get up to speed and deliver a working app. They brought in a contractor who said 2 months, working beta in 1. I pushed pretty hard against this but lost. 2 YEARS later the contractor finally delivered an app they declared "done". It technically worked but was slow as molasses and crashed constantly. My team triaged the worst of it and got it to a semi-usable state before getting approval to build a replacement. It took about 6 months.

pydry 4y ago

I think the ranting is indirectly about the lack of any meaningful unit of account. Financial debt would be just as much of a mess if you couldn't count it. Somehow people think that if only we could explain what it was to people who don't get it the problem would be solved. Nope, just need to be able to measure it and stick a price on it (even if it's not much better than a guess) and let it be put it in a spreadsheet with all the other liabilities. The perpetual attempts at redefinition "so they get it", on the other hand, are all gonna get ignored.

Verdex 4y ago
I think this is important. There's no real way to measure technical debt. The best we seem to have is cyclomatic complexity and lines of code. Not exactly what I would hope for. Alternatively we have 'best practices' (ie someone with an important title somewhere wrote a blog post about it) and 'code smells' (so ... the code makes your tummy feel bad when you look at it, yeah I'm sure that's objective). There are a few corners of the web where people have been trying things, but I don't know if I'm convinced. It is however better than nothing. https://www.sonarsource.com/docs/CognitiveComplexity.pdf https://www.sonarsource.com/docs/CognitiveComplexity.pdf https://www.progsbase.com/blog/flow-charts-of-programming-language-constructs/ https://www.progsbase.com/blog/flow-charts-of-programming-la... I don't think our industry is going to make any headway into a healthy way to deal with technical debt until we can talk objectively about the coding constructs that we're building. There's too many situations where people are conflating familiarity with objective quality. And even when you get past that the politics of having your coding philosophy win out means you can't trust enough people to honestly approach the issue. EDIT: Additionally, you have to worry about the external politics involved. If vendor A says the feature takes 3 months, but vendor B does the feature in 3 weeks, then it it's pretty clear who the customer is going to want to go with. That is until three days after launch when the module vendor B wrote keeps formatting end users' hard drives. OR MAYBE vendor A are just really bad at their jobs and their 3 month version would be the one formatting hard drives. Those who want software written do not have good metrics for how hard anything actually is.
- Volundr 4y ago
  > If vendor A says the feature takes 3 months, but vendor B does the feature in 3 weeks, then it it's pretty clear who the customer is going to want to go with. That is until three days after launch when the module vendor B wrote keeps formatting end users' hard drives. Man, I wish this didn't resonate. I once worked as the lead at a company that decided they wanted to build a mobile app. This wasn't something I or the team had done before, but after researching and considering the features I gave an estimate of 6 months for us to get up to speed and deliver a working app. They brought in a contractor who said 2 months, working beta in 1. I pushed pretty hard against this but lost. 2 YEARS later the contractor finally delivered an app they declared "done". It technically worked but was slow as molasses and crashed constantly. My team triaged the worst of it and got it to a semi-usable state before getting approval to build a replacement. It took about 6 months.