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.
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!
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.
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.
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.
> 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.
I'm not a big fan of this (as you've mentioned it) for multiple reasons. First, use is not necessarily linked with failure rates. Second, predictive analytics that cull the actual failure rates, distort the underlying processes. Third, not every (insert part) is the same. Forth, replacing parts on a predictive schedule (particularly absent a rational policy) is wasteful/inefficient.
Sort of why statistical inference in medicine, is also a failure. This is the same type of faulty reasoning, applied to cars.
Having said that; what does work is:
* Maintaining and monitoring for detection of NON-use failure rates (abnormal production/design/environment issues).
* Maintaining and detection for imminent failure (via live signal extraction via failure mode matching).
* Improving design and production, using high-resolution detection of onset of problems on part post-mortems.
> Now the company not only sells vehicle telemetry but also predictive maintenance notifications.
Intro the vehicle equivalent of "you have to replace your toner, drum, etc". I need to make more money? Send out more PM notices. Who doesn't like more PM notices? :)
> However; I believe there may be an indirect metric
called a proxy metric. Doesn't work in the long-term as their is always drift. But good for eyeballing a dataset and trying to work out a rough estimate of the bounds.
> Maybe that particular solution isn't great but the idea of a "'universally' applicable indirect metric for tech debt for business monitoring" seems tractible.
Naw. The real problem is that "technical debt" is an actual "fiscal" thing; its just not being tracked i.e. you need to link the metric, to the ledger. And then, you have to handle the strategic aspect (when do you actually pay the price, to "pay down" the technical debt). Lastly, couple it with product lifecycle (in the software industry, months). It may be, for example, cheaper to simply retire the product than pay down the debt. Which effectively converts your technical debt to "zero" by strategic decision.
Its not an accident that microservices are very popular (for example); nevermind all the bullshit spouted about it, there is a simple, direct line of reasoning to the entire practice.
> 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.
Wink ;) you cannot automate, brilliance. particularly, in coding. either you have the right mindset to the problem domain, or you don't. frameworks cannot substitute, for understanding. you can fake it with structure (and throwing more machines at it), but at the end of the day, you need, to understand your problem domain, your customer and your orgs fin. structure. You should take a step out from the technical side, and look at it from the business side. Particularly, when you introduce uncertainty, and constraints (business).
I built something similar to what you are talking about; but the purpose was targeted to slightly (sufficiently) different purposes, using similar techs. I prefer to archite...
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.
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.
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.
15 comments
[ 2.3 ms ] story [ 36.0 ms ] thread- Robert Benchley
EDIT: just to be clear I'm very skeptical there are only two kinds of technical debt...
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!
The author acknowledges this in the article:
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.
Countless acquisitions happen where technical due diligence is not performed, and acquirers realize later on they have wildly underestimated the cost.
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.
its a failure of all modern business management methods.
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.
I'm not a big fan of this (as you've mentioned it) for multiple reasons. First, use is not necessarily linked with failure rates. Second, predictive analytics that cull the actual failure rates, distort the underlying processes. Third, not every (insert part) is the same. Forth, replacing parts on a predictive schedule (particularly absent a rational policy) is wasteful/inefficient.
Sort of why statistical inference in medicine, is also a failure. This is the same type of faulty reasoning, applied to cars.
Having said that; what does work is: * Maintaining and monitoring for detection of NON-use failure rates (abnormal production/design/environment issues). * Maintaining and detection for imminent failure (via live signal extraction via failure mode matching). * Improving design and production, using high-resolution detection of onset of problems on part post-mortems.
> Now the company not only sells vehicle telemetry but also predictive maintenance notifications.
Intro the vehicle equivalent of "you have to replace your toner, drum, etc". I need to make more money? Send out more PM notices. Who doesn't like more PM notices? :)
> However; I believe there may be an indirect metric
called a proxy metric. Doesn't work in the long-term as their is always drift. But good for eyeballing a dataset and trying to work out a rough estimate of the bounds.
> Maybe that particular solution isn't great but the idea of a "'universally' applicable indirect metric for tech debt for business monitoring" seems tractible.
Naw. The real problem is that "technical debt" is an actual "fiscal" thing; its just not being tracked i.e. you need to link the metric, to the ledger. And then, you have to handle the strategic aspect (when do you actually pay the price, to "pay down" the technical debt). Lastly, couple it with product lifecycle (in the software industry, months). It may be, for example, cheaper to simply retire the product than pay down the debt. Which effectively converts your technical debt to "zero" by strategic decision.
Its not an accident that microservices are very popular (for example); nevermind all the bullshit spouted about it, there is a simple, direct line of reasoning to the entire practice.
> 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.
Wink ;) you cannot automate, brilliance. particularly, in coding. either you have the right mindset to the problem domain, or you don't. frameworks cannot substitute, for understanding. you can fake it with structure (and throwing more machines at it), but at the end of the day, you need, to understand your problem domain, your customer and your orgs fin. structure. You should take a step out from the technical side, and look at it from the business side. Particularly, when you introduce uncertainty, and constraints (business).
I built something similar to what you are talking about; but the purpose was targeted to slightly (sufficiently) different purposes, using similar techs. I prefer to archite...
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.
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.