4 ms·

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.

by aynyc 6y ago

bryanrasmussen 6y ago
well it's both. So the analogy holds up with real debt in that way.
- Cthulhu_ 6y ago
  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.
  - aynyc 6y ago
    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.
    - etripe 6y ago
      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.

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.

by aynyc 6y ago

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.

bryanrasmussen 6y ago

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

Cthulhu_ 6y ago
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.
- aynyc 6y ago
  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.
  - etripe 6y ago
    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.