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