4 ms·

The “fatal flaw” of skipping maintenance to max out value-add work seems like it could be addressed by ensuring that any accumulated tech debt be properly accou

The “fatal flaw” of skipping maintenance to max out value-add work seems like it could be addressed by ensuring that any accumulated tech debt be properly accounted for, rather than swept under the carpet. You’d consider “productivity” then to be value-add work minus identified tech debt. Since calling out tech debt would hurt leadership’s own metrics, you’d need a mechanism to allow individual engineers to blamelessly (and probably anonymously) report, validate, and attach a cost metric to this tech debt. The org would then be incentivized to balance work that delivers immediate value with work that represents an investment in making the team more efficient and effective at delivering that value in the long run.

datadrivenangel 2y ago
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.
- didgeoridoo 2y ago
  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.
- duderific 2y ago
  > 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.
  - wild_egg 2y ago
    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
jimbokun 2y ago
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.
- didgeoridoo 2y ago
  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.
kayo_20211030 2y ago
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.
- haskellandchill 2y ago
  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.
  - kayo_20211030 2y ago
    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?
    - esafak 2y ago
      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.
lelanthran 2y ago
> 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.
- didgeoridoo 2y ago
  > 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.

datadrivenangel 2y ago

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.

didgeoridoo 2y ago
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.
duderific 2y ago
> 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.
- wild_egg 2y ago
  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

jimbokun 2y ago

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.

didgeoridoo 2y ago
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.

kayo_20211030 2y ago

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.

haskellandchill 2y ago
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.
- kayo_20211030 2y ago
  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?
  - esafak 2y ago
    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.

lelanthran 2y ago

> 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.

didgeoridoo 2y ago
> 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.