Technical Debt Is a Myth

Post by iLoveOncall » Tue, Nov 08, 2022, 11:24 PM UTC

svnt wrote: post #13

iLoveOncall wrote: post #6

I'm not sure what what to think of the article because I think the definition he chose for technical debt is extremely reductive. No, technical debt does not only come from taking shortcuts. I would even go as far as saying that most of the time it does not come from taking shortcuts. - You wrote a perfectly engineered system in Cobold 30 years ago that was state of the art then? Well, now all your Cobold developers…

> It's not debt. It's stuff that used to be perfectly fine and due to no fault of yours is not anymore. The risk of this happening is more or less measurable and is the debt. Denying responsibility doesn’t make the debt not exist. It might mean you’re so far removed from understanding how your (sub)systems function that you’re unable to assess it. It may be so complex that no one is able to quantify it, in which case…

Post by yunwal » Wed, Nov 09, 2022, 10:35 PM UTC

svnt wrote: post #12

yunwal wrote: post #5

Earlier quoted context omitted.

Isn’t the point of using the phrase “technical debt” that you should be doing this? It’s an idealistic phrase, not one that’s supposed to apply to every organization.

It applies to every organization. You have to take some of it on unless you turn minerals into revenue using only processes and systems that can be recreated from scratch at will irrespective of who your employees are. Since no one can do that, everyone has it. Taking it on unnecessarily is bad for the health of the business and worse than financial debt because technical debt, unlike financial debt, is not fungible.