Two Kinds of Tech Debt and How to Pay It Down

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.