Two Kinds of Tech Debt and How to Pay It Down(blog.kylegalbraith.com)
blog.kylegalbraith.com
Two Kinds of Tech Debt and How to Pay It Down
https://blog.kylegalbraith.com/2018/10/22/two-kinds-of-tech-debt-and-how-to-pay-it-down/
15 comments
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.
Countless acquisitions happen where technical due diligence is not performed, and acquirers realize later on they have wildly underestimated the cost.
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.
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.
Sure - it’s something you can sweep under the rug by not having any accountability on it.
Yeah, I'm not saying I agree with it, I just comprehend how it happens.
nobody has a system that can track this.
its a failure of all modern business management methods.
its a failure of all modern business management methods.
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. 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 architect the solutions rather than rely on (insert methodology); that is, to take into account the system dynamics and test proposed codebases using different types of methods, rather than rely on the current methods of remediation. But this necessarily, increases tech debt. But it does so, for the right reasons. And that, makes ALL the difference.
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 architect the solutions rather than rely on (insert methodology); that is, to take into account the system dynamics and test proposed codebases using different types of methods, rather than rely on the current methods of remediation. But this necessarily, increases tech debt. But it does so, for the right reasons. And that, makes ALL the difference.
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.
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.
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.
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.
"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...
- Robert Benchley
EDIT: just to be clear I'm very skeptical there are only two kinds of technical debt...
> EDIT: just to be clear I'm very skeptical there are only two kinds of technical debt...
The author acknowledges this in the article:
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."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!
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!
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.