[close04]

> Planned obsolescence/long con

They were most likely just kicking the ball down the road either thinking that a more permanent solution will be applied in the 2 decades to come, or just not caring at all because they won't be around in 20 years.

Technical debt tends to accrue this way and many times it's not in bad faith. It's meant as a short term solution to buy some time and ends up being permanent because someone doesn't understand what's the point in spending more money to fix an issue that was "obviously" fixed already.

[LinuxBender]

I wish I could upvote this a few times. I have created so many "just use this for now" solutions that have been in use for more than a decade. The real problem never gets fixed for exactly the reason you stated. "It's working, I don't see a problem" (says the manager) and priorities go to other more burning issues. The debt adds up to thousands of small cuts and and ultimately the sum of the debt becomes very expensive to maintain in terms of hours updating, debugging, getting someone who knows the history, finding old jira issues, etc... I think can-kicking eventually contributes to burn-out.

[buran77]

> "It's working, I don't see a problem" (says the manager) and priorities go to other more burning issues.

Well you know the old saying, save the grease for the squeaky wheels. When you face a major hurdle sometimes the best course of action is to take a shortcut just to avoid it and fix it later when you can properly allocate resource for a solid fix. But most times after the fix it's hard to justify fixing it "again".

I've had managers who said "I understand the issue but we have a budget and more critical cracks to fix", and I've had managers who said "what are you going on about, looks good to me". Result is the same but the potential of each attitude is vastly different. The first kind of manager knows when "that" crack becomes a priority. The second kind of manager is unaware there's a crack.

[LeonM]

Nothing is more permanent than a temporary solution

[mark-r]

When I went to the University of Minnesota in the late '70's, there were "temporary" buildings installed just after WWII that were still in use.

[bilekas]

I'm taking this with me.

[kokey]

That's not a problem since you're just going to quickly be rewriting it all using this new language, framework, development methodology, deployment mechanism and infrastructure technology that solves all the old problems so surely it'll fix these problems too.

[rectang]

We can help by preferring and recommending tools which allow for auditability of technical debt.

For example, you can grep a Rust code base for "unwrap", "expect", and "unsafe", while in other languages, ignored return codes or unchecked exceptions are harder to detect.

Similarly, (if I am not mistaken) you can grep Swift code for "try", and find every call site that might throw an exception[1]. Can't do that in Java, C#, or Python!

Tool designers can help by differentiating their products through how well they allow for tracking technical debt.

[1] joeduffyblog.com/2016/02/07/the-error-model/#easily-auditable-callsites

[_asummers]

It's also possible that all the fixes for this were declined by management in the interest of time. If you have a system you can quickly patch suboptimally to get the larger fire lowered, I can see the decision being made to do so. That's clearly irresponsible on management if that choice was made, considering the problem they were dealing with at the time, but if the decision is between "not finishing" and "these few systems still have bugs", I can rationalize it.

[toyg]

> That's clearly irresponsible on management

It is not irresponsible to use temporary fixes in the face of a hard deadline - what is irresponsible is not going back post-deadline to deal with them with a long-term view. Unfortunately, bonuses typically don't get paid for long-term results...

[Leherenn]

Even then, is it? If the choice is between having a major restructuring which results in breaking compatibility and similar once, or kicking the can every 20 years with a minimal patch; I can certainly see the later being the rational decision.

[buran77]

It just so happens that 20 years later both the engineer and the manager have moved on and you find about the patch you needed when your production goes down. And even the corner cutting rarely implies just a "minimal" patch anyway.

[toyg]

Particularly when there is a very hard deadline, as in this case, it is absolutely rational to make it work now and worry about long-term correctness later.