That's the thing though! Quality :tm: is very hard to account for, especially when the quality is in the system, tooling, and process to build the quality end product.

And often times technical debt isn't actually something you can put on the balance sheet or bug tracker. It's all the little investments in the future that are deferred or skipped. That one code change is so minor you can phone in the review, you'll write better documentation for that new feature in a few weeks when you have some time, etc.

It’s a good practice to note things for later and why they should be done though, right? Even if it is never intended to be worked on, noting that you would write more docs for this class but you don’t have time is an important indicator of productive capacity for leadership. If I start seeing a lot of that as an executive, I should start to worry if we’re building our value-add on a foundation of sand.

> you'll write better documentation for that new feature in a few weeks when you have some time

The trick here is to make a ticket for it. At least then, it can be prioritized appropriately, instead of disappearing into a void.

I don't think I've ever seen a ticket to write docs get prioritized. The backlog is just another void that happens to make people feel like they're doing something useful

Tech debt is categorically unquantifiable. Most of the time it's more of a feeling than a number, and it's not an accessible number ever. What's the ROI on paying down debt? Hold as is, renegotiate, or extinguish? It's the same calculation that goes into deciding which of the five thousand value-add proposals to prioritize. The piece is unconvincing for that reason. There's an assumption that TD is known, and an implicit assumption that the ROI on its remediation is known. Neither of those is true. Systems evolve to where they are, with all their TD warts, because value-add was prioritized.... and then we have TD. I reckon we should just live with that uncertainty, move the product forward, calculate ROI using the same bogus productivity metrics we always have, and stop inventing "better" systems which are just another form of magic, but manage to suck up time and resources not required by accepting on faith the old bogus metrics.

It’s really not unquantifiable. I read “How to Measure Anything in Cybersecurity Risk” and it was an eye opener. Using a table of risks and outcomes with associated probabilities and 90% confidence intervals of dollar impacts we can quantify categories of technical debt.

If "Cybersecurity Risk" were the only form of technical debt, we'd be just fine(?). Or, at least, we'd have some sort of metric. It wouldn't be a good one, but it'd be there. Chance of a breach: 1%. Existential or not? Probably not. Cost of mitigation? Probably small. Worth addressing? Mostly no, unless you're a regulated entity; then it's mandatory. Quantifiable, for this narrow case, but what of the rest?

Apply the same mentality to other things. If the cybersecurity folks can quantify risk so can you. Are you keeping track of your supply chain? How modular is your code? How easy to refactor is your code? You could think of reasonable metrics to measure various aspects of technical debt. It won't be perfect but it's better than nothing.

I think a bad metric is very much worse than nothing. It sucks away time to record, debate, report, and discuss. It encourages bad decision making. If you throw up a number people will give it weight, even if it's stupid. Multiplying 6 gut checks and trying to make a decision about engineering direction is like tracking someone's mood by the metric of whether they ate an odd or even number of calories yesterday. There's theoretically a signal under all that noise, but the direct gut-check or any number of qualitative clues are so much better than the distracting number.

I agree whole-heartedly. A bad metric is a curse. It's misleading, resulting in waste, and falsely reassuring simply because it exists as a number. +100 on the gut-check qualitative approach

You can say whatever you want, there are studies backing up the beneficial impact of quantitative over qualitative.

They'd be quantitive studies of quality, I hope.

> The “fatal flaw” of skipping maintenance to max out value-add work seems like it could be addressed

Who says it's a flaw? And even if it is, who says it needs to be addressed?

It's all contextual: tech debt used to be a flaw that could destroy a product, but nowadays I'm seeing teams rewriting components of their products every 18 months in whatever new fad seems to come along.

Why care about debt when it's going to be written off in the future?

And even if it isn't, the person who accumulated the debt did so by adding features - he's the man that delivers, so he gets to go up the ladder

It's not a fair world: anyone who actually cares about bugcount, product quality, customer satisfaction and sustainable velocity just isn't going to get recognised for the fires they prevented.

> Who says it’s a flaw?

The author of the article.

> who says it needs to be addressed?

I think you’ve misread my post. What is being “addressed” isn’t technical debt itself, but rather the author’s proposed failure mode of totally ignoring muda to focus on overly-incentivized “value add”, which he correctly forecasts will slowly destroy the product and company.

I’m saying that this doesn’t have to be a failure mode, so long as you acknowledge and record when muda has been skipped, and take that into consideration when holding leadership accountable to productivity metrics.

He mentions this in the article.

For important but non revenue producing aspects like security, there are actually insurance markets now for breaches. The insurance companies lower your premiums based on their assessment of overall risk, making your exposure more quantifiable.

He mentions this in the article to say that it’s a “fatal flaw” that might cause this methodology to not work in your org. However, he also fatalistically assumes that skipping muda is a failure case, rather than just a realistic response to balancing short vs long term considerations.

I suggest above that muda should either 1) be worked on, or 2) the fact that it’s being deferred should be explicitly captured. And, since there are competing interests (leadership is accountable to net productivity while ICs are not) the deferral capture needs to be anonymous to prevent top-down pressure in the direction of ignoring tech debt accumulation.