Hacker News Reader

Comment by iLoveOncall | Hacker News Reader

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 have retired and you need to add new features to that tool. It's tech debt.

- Your tool was built to support 100 users but now it needs to support 100M? It's tech debt.

- You were getting some data from the Google Stadia API? Tech debt.

- You're using a library that just got an important security update? Tech debt.

As another commenter pointed out, the term "debt" was wrongly chosen. It's not debt. It's stuff that used to be perfectly fine and due to no fault of yours is not anymore.

View on HN

A lot of your framing has to do with what's expected of the system. Like, scaling from 100 users to 100M is an expectation not a property of the software. Making that library _more_ secure is also an expectation. Expectation becomes debt when your current expectation exceeds the limits of the system. When that happens it's largely because someone, often not a developer, changed the expectations. When that happens the difference between the expectations and actual system has to reconcile somehow and that's usually via some "shortcut" and there's some associated cost.

So, within your framing, the point is just that when things change (due to no fault of your own) the whole organization has to adjust expectations or you have an organizational issue.

> 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 I suppose “it doesn’t exist” might be accurate enough — either your business fails or it doesn’t based on the success of your subsystems, and your business outcome is the measurement. I’d rather have someone else be the measurement.

Another commenter explained perfectly what I would have answered myself here: https://news.ycombinator.com/item?id=33515409

It's not a failure of anyone or anything, it's just a change in requirements.

Technical entropy.

Entropy is unavoidable is the outcome of any work occurring.

It’s a cool-sounding term. I think I agree if things are viewed zoomed out enough (temporally), but isn’t the issue actually (unknown, outdated) structure, not entropy? The entropy is what comes about as the old structure gives way.

> Well, now all your Cobold developers have retired and you need to add new features to that tool. It's tech debt.

A new feature isn't tech debt... it's a new feature. I don't know for other people but at my workplace they're two very different types of TFS items.

No, the tech debt here would be to have a program in Cobold that nobody can support.

Reply on news.ycombinator.com