4 ms·
> 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 need
by lelanthran 3y 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 3y 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.