On Exactitude in Technical Debt | Hacker News Reader

On Exactitude in Technical Debt

oreilly.com

Technical debt is not the cost of repaying the debt: it is the cost of owning the debt.

More developers and eng managers need to understand this.

well it's both. So the analogy holds up with real debt in that way.

It's both indeed; you pay interest over time, and when you do commit to paying it off, you don't just pay off the original debt but a lot of the accrued junk to work around it as well.

No wonder most replacement projects I've worked on (which, come to think of it, has been every project) have been just complete rebuilds; the original was considered bankrupt.

I mean I get it in some cases (like when we replaced a Flash front-end with a SPA; you can't fix a technology that is end of life), but in a lot of cases they should have invested in just slowly fixing and replacing the old application, instead of going for the big rewrite.

There was no reason to replace a working C# application with all kinds of 3rd party / customer integrations with a massive Java microservices architecture, not when after two years there was still nothing but fancy slides to show.

Most rewrite I've been part of weren't driven by technical debt. It's driven by change of business requirements and technology retirement due to various conditions. For example, we moved from RDMS to Hadoop due to scale of the data we were handling, and now to Spark.

The most common technical debt I've seen is lack of documentation and lack of design. It's gotten worse in recent years because the concept of Agile and MVP are forcing/changing everyone to glue services together without a solid requirement and any shape of design.

Interesting. I think maybe we should stop synonimising "business" with "management". The rewrites I've seen are due to changing "business" (read: management) requirements, that had little to do with an actually changing business. These were new "hotshot" execs coming in and wanting to expand their influence or make their mark, and the best way they saw fit was dragging developers into it.

Your mileage might vary. I'm open to people with longer or different experience than my own having observed another reality, as this is just anecdata.

> If you don’t touch code, it doesn’t intrinsically degrade.

This is one misunderstanding of code quality which takes an absolute approach to measuring code health. Code health is relative to the changing requirements of it’s use. If you suddenly add a requirement that doesn’t fit existing design assumptions, the code hasn’t changed but the relative to the ideal has deviated...without touching the code.

The tech debt metaphor is not perfect. The pandemic has given us all a better metaphor: the code health epidemic. I’ve written about it here: https://sovilon.com/2020/05/15/atd-epidemic-prevention-respo...

one also has to keep in mind things like bugs, external dependencies, security, and the environment in which its executing.

code does rot

>>> If you don’t touch code, it doesn’t intrinsically degrade.

That premise is factually wrong, code degrades over time because everything the code interfaces with is shifting over time (OS, compiler, interpreter, dependencies, etc...).

Reply on news.ycombinator.com