4 ms·

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.
- paulgrant999 8y ago
  > 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 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.

paulgrant999 8y ago
> 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.