3 ms·

Having been in this space for 25 years now, here's my take: Tech Debt is almost always a few things in disguise: 1. Product Failure - The person with the fina

Having been in this space for 25 years now, here's my take: Tech Debt is almost always a few things in disguise: 1. Product Failure - The person with the final say on the product has poor taste. They poorly understand the tradeoffs their tech stack gives and how it influences their product. And most importantly they hate their customers and don't understand their needs. 2. Marketing and Sales dominance - The product organization might be competent but they have been driven out of the decision making venues in the company. So marketers and sales make the decisions and hand them down to product to deal with, resulting in tone deft decisions even as the company continues to make good money, the product itself erodes, until competitors arrive and instantly wipe out the business. 3. success and shift - The product, which was initially a success, has stagnated. The product itself was so successful that it created an entire new market with competitors that resulted in commodifying the product. Now the company is frantically looking for a pivot to keep growing the business, resulting in the original successful product drying up even faster. 4. Leadership void - The product was made by a strong, pioneering leader. They might not even consider themselves such a leader, but after they move on, the product fails without their support. The replacement leader might not even be bad at running the business for a time, but eventually focusing on EBITA alone won't inspire people, and the product will erode through churn. 5. Press Release driven development - The company operates by making a moat around its original core offering and they have a semi-monopoly in their space. So the only way to drive more revenue is to sell services that cost more to already existing customers. As a result, teams build products that are made to drive hype cycles and press releases -- once the product is shipped, the major players get promotions and move on to the next exciting product instead of supporting the now-shipped product.

Yabood 4y ago
All valid points, but let's not forget that development teams are a major contributor too.
- sublinear 4y ago
  I think this is highly underrated. The ideal is when a team's experience actually matches the project they're assigned. They need to be up to the task. This requires management to be at least more experienced than the teams they manage and to make good hiring and placement decisions. This is not just number of years in the industry, but the average number of years spent at any single company. They need to have seen the long tail of maintenance in the development lifecycle on projects they were wholly responsible for.
  - BackBlast 4y ago
    Agreed. I've seen an org that essentially let the devs run the show for picking timelines, technologies, features. It was a disaster. Endless design by committee, no progress, too many abstractions, and on and on it went with developer created problems after being given free reign with only general direction. Of course, this is a management issue at the root, all problems are, aren't they? :) Creating functional software engineering orgs is hard. Between dysfunctional management, lack of support from other business departments, or problems originating from the devs themselves. It's pretty easy to feel when it's not working properly and know roughly where the problem lies. But solving it properly is hard stuff.
- karmakaze 4y ago
  In my view, the listed items are one step away from tech debt. They may be the pressures that lead to tech debt, but it's the devs that wrote and shipped the tech debt. I personally have maintained the quality bar of projects so that they ship later than originally scheduled. I may not be popular at the time, but eventually people start to notice that projects that I tech lead do complete (eventually) and run well after they go live with much less follow-on maintenance and support. Performance being built into v1 is one of those things. I'm not talking about an MVP for a startup, but extensions to an already high scale platform.
mjr00 4y ago
Also 6: tech debt being another term for "code I personally do not understand," or "software written in a way different than I would write it." The article calls this out; > Turns out some apparent tech debt was actually code that was better left untouched, had there been better documentation. We documented what we would not refactor or remove. > Better clarity on the design and architecture of the code, enabled us to make better judgement calls when we had to cut corners due to the time constraints. There is certainly real tech debt. But I have lost count of the number of times in my career I've heard a bright, but less experienced, developer claim that because a certain piece of code uses Formerly Popular Framework A from 7 years ago when it was written instead of Current Popular Framework B, it is unmaintainable tech debt, despite it having tests, a working CI pipeline, working monitoring, etc.
- rileymat2 4y ago
  It maybe tech debt depending on a lot of context, with old tech you get into a lot of situations like this: https://stackoverflow.com/questions/9318895/how-to-integrate-websockets-on-top-of-a-classic-asp-web-application https://stackoverflow.com/questions/9318895/how-to-integrate... Sure, there is an answer to the question, it is a little messy, not too bad, do this 30 times and you have a disaster to maintain. Formerly popular is also a red flag, over time it will get harder to hire. Resources and documentation will go black.
  - mjr00 4y ago
    > It maybe tech debt depending on a lot of context, with old tech you get into a lot of situations like this: Yeah absolutely that's a fair example of tech debt, where a tech stack is so old that it's difficult to impossible to support modern features. But "classic ASP doesn't support this modern feature requested by product" is a lot different than "I don't like working with classic ASP." > Formerly popular is also a red flag, over time it will get harder to hire. Really depends. Java is a great example. Very unsexy, not too many startups beginning life as a Java shop, most code is likely "legacy" by this point. But Java is so ubiquitous, if I were a Java shop I wouldn't be worried whatsoever about running out of Java expertise anytime soon. Maybe in 50 years. On the other hand, if you were a legacy Java shop that jumped on the Scala hype train at its peak 8-10 years ago, or God forbid you built something in Haskell when it was getting touted as the next big thing, you're in a far more precarious situation. Ironically, many Java shops tried out Scala as a way to move their Java codebases forward, and now their now-legacy Scala 2.xx codebase is a way larger technical dumpster fire than their Java codebase.
pprotas 4y ago
It’s like you are describing my employer…
goto11 4y ago
A major source of tech debt is when you get a better understanding of the domain and realize some of the early design decision was not optimal.

Yabood 4y ago

All valid points, but let's not forget that development teams are a major contributor too.

sublinear 4y ago
I think this is highly underrated. The ideal is when a team's experience actually matches the project they're assigned. They need to be up to the task. This requires management to be at least more experienced than the teams they manage and to make good hiring and placement decisions. This is not just number of years in the industry, but the average number of years spent at any single company. They need to have seen the long tail of maintenance in the development lifecycle on projects they were wholly responsible for.
- BackBlast 4y ago
  Agreed. I've seen an org that essentially let the devs run the show for picking timelines, technologies, features. It was a disaster. Endless design by committee, no progress, too many abstractions, and on and on it went with developer created problems after being given free reign with only general direction. Of course, this is a management issue at the root, all problems are, aren't they? :) Creating functional software engineering orgs is hard. Between dysfunctional management, lack of support from other business departments, or problems originating from the devs themselves. It's pretty easy to feel when it's not working properly and know roughly where the problem lies. But solving it properly is hard stuff.
karmakaze 4y ago
In my view, the listed items are one step away from tech debt. They may be the pressures that lead to tech debt, but it's the devs that wrote and shipped the tech debt. I personally have maintained the quality bar of projects so that they ship later than originally scheduled. I may not be popular at the time, but eventually people start to notice that projects that I tech lead do complete (eventually) and run well after they go live with much less follow-on maintenance and support. Performance being built into v1 is one of those things. I'm not talking about an MVP for a startup, but extensions to an already high scale platform.

mjr00 4y ago

Also 6: tech debt being another term for "code I personally do not understand," or "software written in a way different than I would write it." The article calls this out; > Turns out some apparent tech debt was actually code that was better left untouched, had there been better documentation. We documented what we would not refactor or remove. > Better clarity on the design and architecture of the code, enabled us to make better judgement calls when we had to cut corners due to the time constraints. There is certainly real tech debt. But I have lost count of the number of times in my career I've heard a bright, but less experienced, developer claim that because a certain piece of code uses Formerly Popular Framework A from 7 years ago when it was written instead of Current Popular Framework B, it is unmaintainable tech debt, despite it having tests, a working CI pipeline, working monitoring, etc.

rileymat2 4y ago
It maybe tech debt depending on a lot of context, with old tech you get into a lot of situations like this: https://stackoverflow.com/questions/9318895/how-to-integrate-websockets-on-top-of-a-classic-asp-web-application https://stackoverflow.com/questions/9318895/how-to-integrate... Sure, there is an answer to the question, it is a little messy, not too bad, do this 30 times and you have a disaster to maintain. Formerly popular is also a red flag, over time it will get harder to hire. Resources and documentation will go black.
- mjr00 4y ago
  > It maybe tech debt depending on a lot of context, with old tech you get into a lot of situations like this: Yeah absolutely that's a fair example of tech debt, where a tech stack is so old that it's difficult to impossible to support modern features. But "classic ASP doesn't support this modern feature requested by product" is a lot different than "I don't like working with classic ASP." > Formerly popular is also a red flag, over time it will get harder to hire. Really depends. Java is a great example. Very unsexy, not too many startups beginning life as a Java shop, most code is likely "legacy" by this point. But Java is so ubiquitous, if I were a Java shop I wouldn't be worried whatsoever about running out of Java expertise anytime soon. Maybe in 50 years. On the other hand, if you were a legacy Java shop that jumped on the Scala hype train at its peak 8-10 years ago, or God forbid you built something in Haskell when it was getting touted as the next big thing, you're in a far more precarious situation. Ironically, many Java shops tried out Scala as a way to move their Java codebases forward, and now their now-legacy Scala 2.xx codebase is a way larger technical dumpster fire than their Java codebase.

pprotas 4y ago

It’s like you are describing my employer…

goto11 4y ago

A major source of tech debt is when you get a better understanding of the domain and realize some of the early design decision was not optimal.