at what point does “temporary fix” just become part of the architecture?

Posted by Nexthink_Quentin@reddit | sysadmin | View on Reddit | 21 comments

feel like every system has at least one thing that was supposed to be short term and is now… permanent

curious what people are quietly relying on that was never meant to last

[-]

ErrorID10T@reddit

As soon as the ticket or project is closed.

[-]

JasonDJ@reddit

Do you want tech debt?
Because this is how you get tech debt.

I'm also guilty.

[-]

ErrorID10T@reddit

You're always going to have tech debt. Documenting it and knowing when it can be scheduled for a later date is how you avoid that tech debt becoming a problem.

[-]

himji@reddit

This. As soon as the ticket/job/task is closed nobody ever remembers until it goes wrong

[-]

Obvious-Water569@reddit

When it works well enough that leadership lose interest.

I've even been known to intentionally hobble my own temporary fixes so the thing technically works but badly enough that it still annoys people. Without doing that, people stop being invested in actually fixing it properly.

[-]

NotYetReadyToRetire@reddit

"When it works well enough that leadership lose interest."

Exactly. I once cobbled together a temporary solution for an issue while the team supporting the area was planning the permanent fix. Ten years later at a different employer I was still getting questions about and requests for improvements to that "temporary" fix.

[-]

pdp10@reddit

This. Frequently, the biggest danger is exceeding the attention span of relevant decision-makers.

For projects that are stretching on too long, it's human nature to tend to want to be able to call them "Done", even if it comes at great trade-off. And if the trade-off isn't owned by that decision-maker, then it doesn't even enter the equation.

However, there's also a human tendency not to want to revisit things that are "Done". Especially if it comes with resourcing request. This is the really dangerous part, where someone refuses to pay off that technical debt, that they may have been the one insisting upon, in the first place.

Try never to admit openly, but do consider these human risks when planning projects. For the most part, this means keeping things small, fighting scope-creep that's going to drag things out and open the door to technical debt.

[-]