6 ms·

Two Kinds of Tech Debt and How to Pay It Down

50 points by kylegalbraith 8y ago

bryanrasmussen 8y ago
missing the concept of tech depreciation, if your codebase has a debt of 2000 codedollars and a value of 10000 codedollars, those value codedollars are probably depreciating over time and moving to the debt column.
andy_ppp 8y ago
"There are two kinds of people in the world, those who believe there are two kinds of people and those who don't." - Robert Benchley EDIT: just to be clear I'm very skeptical there are only two kinds of technical debt...
- bonniemuffin 8y ago
  No taxonomy/segmentation/categorization is perfect, but these structures provide a useful starting point for conversation. If you believe there's another kind of tech debt, tell us what it is and how it differs from the two kinds described in that article so we can be convinced and expand our understanding of the world!
- lthemick 8y ago
  > EDIT: just to be clear I'm very skeptical there are only two kinds of technical debt... The author acknowledges this in the article: "Of course, there are more than two types of tech debt, but I think the two we talk about here cover a lot of ground."
eagsalazar2 8y ago
At my company we also always talk about two kinds of tech debt but in a totally different way: (1) "bad" code debt is basically high interest where the longer you wait the refactor story grows and grows and gets scarier and scarier. (2) "good" is interest free or low interest debt which you should defer paying as long as possible so you can focus on more important immediate things. This is usually achievable when the thing you are ignoring can be neatly encapsulated and doesn't affect the rest of your code as the codebase grows and evolves. Usually we talk about this distinction when deciding to defer work for hypothetical scaling. For example we had an app that required HIPAA compliance and had a chat feature, since we were initially deploying to a few hundred users for a pilot and our main short term goals were about learning/validating we just build it using polling since none of the other sockets based alternatives were easily HIPAA compliant. It worked great for the pilot and took like 2hrs to implement and because it was so simple we were able to evolve the chat experience really quickly with different features as we got feedback.
ErikAugust 8y ago
One of the things about technical debt that I have seen is a lack of a real accounting system that at least ballparks the costs in real dollars. Countless acquisitions happen where technical due diligence is not performed, and acquirers realize later on they have wildly underestimated the cost.
- hinkley 8y ago
  And that's probably why this doesn't happen. If you have bookkeeping that shows that you're a bad acquisition target you go out of business and are considered a failure. If you don't then you get bought by someone idealistic and you're considered something of a success.
  - ErikAugust 8y ago
    Sure - it’s something you can sweep under the rug by not having any accountability on it.
    - hinkley 8y ago
      Yeah, I'm not saying I agree with it, I just comprehend how it happens.
- paulgrant999 8y ago
  nobody has a system that can track this. its a failure of all modern business management methods.
  - sovietmudkipz 8y ago
    I went to a usergroup meet up that talked about the business of large vehicle monitoring (18 wheelers, farm machinery, buses). Basically, there is this system installed on all (?) vehicles called the CANBUS that supports tracking different metrics. E.g. hydraulic pressure, current RPM of wheels, etc etc. Through these raw streams of data and through post mortem analysis of situations, the company started realizing they could predict when things would wear out. They experimented with things like how many times does a bus door open and close before failure is induced to learn more about how the data they had access to could be used for predictions. Now the company not only sells vehicle telemetry but also predictive maintenance notifications. The point of this whole story is this. I believe it's hard to quantify tech debt without being familiar with the code. However; I believe there may be an indirect metric that can apply to most cases to let businesses know when to invest in paying down tech debt. Maybe it's something raw and kludge-y like "for every 5 'additive' tickets (user stories, features, bugfixes, etc), one additional ticket should be created to refactor the system." Maybe that particular solution isn't great but the idea of a "'universally' applicable indirect metric for tech debt for business monitoring" seems tractible. --- P.S. Personally, I've toyed with the idea of a 90/10 technology business where 90% of all work done is invested in production monitoring, building metrics, improving any performance bottlenecks, simplifying the codebase (literally reducing LOC where possible), information sharing (recorded tech talks about parts of the system with quizzes at the end), building testings, investing in deploying the system quickly and painlessly, and getting people set up to work ASAP (Vagrant, documentation, w/e). Only 10% would be spent on new feature development. Tech debt is always being paid down in this setup.
tcopeland 8y ago
Another scenario is when an acquisition occurs for the data a company has collected and so the codebases are quietly retired. In that situation there's still some value in paying down some technical debt - security updates on libraries and whatnot - but there's a point at which the decommissioning effort becomes the primary driver.
bitfhacker 8y ago
Sonarqube is a great way of measuring technical debt. Where I'm currently working, we mark the sources with issues (each issue have a default time to resolve it - > measuring time we measure euros). In each developement, teams start looking at Sonar to clean issues, so that we left the code better than it was.
thaumaturgy 8y ago
You can take advantage of the reusability part of software development to pay down technical debt in a way that's impossible with traditional debt. Developers and businesses should have a well-maintained toolbox, library, or framework that they use for just about everything they work on. The longer you use the same toolbox, the better the tools will get; just improve them a little bit every time you use them and deploy those improvements to as many projects as possible. This gets hard to do in environments that are always chasing the new thing.

50 points by kylegalbraith 8y ago

missing the concept of tech depreciation, if your codebase has a debt of 2000 codedollars and a value of 10000 codedollars, those value codedollars are probably depreciating over time and moving to the debt column.

andy_ppp 8y ago

"There are two kinds of people in the world, those who believe there are two kinds of people and those who don't." - Robert Benchley EDIT: just to be clear I'm very skeptical there are only two kinds of technical debt...

bonniemuffin 8y ago
No taxonomy/segmentation/categorization is perfect, but these structures provide a useful starting point for conversation. If you believe there's another kind of tech debt, tell us what it is and how it differs from the two kinds described in that article so we can be convinced and expand our understanding of the world!
lthemick 8y ago
> EDIT: just to be clear I'm very skeptical there are only two kinds of technical debt... The author acknowledges this in the article: "Of course, there are more than two types of tech debt, but I think the two we talk about here cover a lot of ground."

eagsalazar2 8y ago

At my company we also always talk about two kinds of tech debt but in a totally different way: (1) "bad" code debt is basically high interest where the longer you wait the refactor story grows and grows and gets scarier and scarier. (2) "good" is interest free or low interest debt which you should defer paying as long as possible so you can focus on more important immediate things. This is usually achievable when the thing you are ignoring can be neatly encapsulated and doesn't affect the rest of your code as the codebase grows and evolves. Usually we talk about this distinction when deciding to defer work for hypothetical scaling. For example we had an app that required HIPAA compliance and had a chat feature, since we were initially deploying to a few hundred users for a pilot and our main short term goals were about learning/validating we just build it using polling since none of the other sockets based alternatives were easily HIPAA compliant. It worked great for the pilot and took like 2hrs to implement and because it was so simple we were able to evolve the chat experience really quickly with different features as we got feedback.

ErikAugust 8y ago

One of the things about technical debt that I have seen is a lack of a real accounting system that at least ballparks the costs in real dollars. Countless acquisitions happen where technical due diligence is not performed, and acquirers realize later on they have wildly underestimated the cost.

hinkley 8y ago
And that's probably why this doesn't happen. If you have bookkeeping that shows that you're a bad acquisition target you go out of business and are considered a failure. If you don't then you get bought by someone idealistic and you're considered something of a success.
- ErikAugust 8y ago
  Sure - it’s something you can sweep under the rug by not having any accountability on it.
  - hinkley 8y ago
    Yeah, I'm not saying I agree with it, I just comprehend how it happens.
paulgrant999 8y ago
nobody has a system that can track this. its a failure of all modern business management methods.
- sovietmudkipz 8y ago
  I went to a usergroup meet up that talked about the business of large vehicle monitoring (18 wheelers, farm machinery, buses). Basically, there is this system installed on all (?) vehicles called the CANBUS that supports tracking different metrics. E.g. hydraulic pressure, current RPM of wheels, etc etc. Through these raw streams of data and through post mortem analysis of situations, the company started realizing they could predict when things would wear out. They experimented with things like how many times does a bus door open and close before failure is induced to learn more about how the data they had access to could be used for predictions. Now the company not only sells vehicle telemetry but also predictive maintenance notifications. The point of this whole story is this. I believe it's hard to quantify tech debt without being familiar with the code. However; I believe there may be an indirect metric that can apply to most cases to let businesses know when to invest in paying down tech debt. Maybe it's something raw and kludge-y like "for every 5 'additive' tickets (user stories, features, bugfixes, etc), one additional ticket should be created to refactor the system." Maybe that particular solution isn't great but the idea of a "'universally' applicable indirect metric for tech debt for business monitoring" seems tractible. --- P.S. Personally, I've toyed with the idea of a 90/10 technology business where 90% of all work done is invested in production monitoring, building metrics, improving any performance bottlenecks, simplifying the codebase (literally reducing LOC where possible), information sharing (recorded tech talks about parts of the system with quizzes at the end), building testings, investing in deploying the system quickly and painlessly, and getting people set up to work ASAP (Vagrant, documentation, w/e). Only 10% would be spent on new feature development. Tech debt is always being paid down in this setup.

tcopeland 8y ago

Another scenario is when an acquisition occurs for the data a company has collected and so the codebases are quietly retired. In that situation there's still some value in paying down some technical debt - security updates on libraries and whatnot - but there's a point at which the decommissioning effort becomes the primary driver.

bitfhacker 8y ago

Sonarqube is a great way of measuring technical debt. Where I'm currently working, we mark the sources with issues (each issue have a default time to resolve it - > measuring time we measure euros). In each developement, teams start looking at Sonar to clean issues, so that we left the code better than it was.

thaumaturgy 8y ago

You can take advantage of the reusability part of software development to pay down technical debt in a way that's impossible with traditional debt. Developers and businesses should have a well-maintained toolbox, library, or framework that they use for just about everything they work on. The longer you use the same toolbox, the better the tools will get; just improve them a little bit every time you use them and deploy those improvements to as many projects as possible. This gets hard to do in environments that are always chasing the new thing.