𝗪𝗵𝘆 𝗤𝘂𝗶𝗰𝗸 𝗙𝗶𝘅𝗲𝘀 𝗕𝗲𝗰𝗼𝗺𝗲 𝗣𝗲𝗿𝗺𝗮𝗻𝗲𝗻𝘁

𝗪𝗵𝘆 𝗤𝘂𝗶𝗰𝗸 𝗙𝗶𝘅𝗲𝘀 𝗕𝗲𝗰𝗼𝗺𝗲 𝗣𝗲𝗿𝗺𝗮𝗻𝗲𝗻𝘁

Your system breaks on Friday afternoon.

Customers suffer. Alerts ring. Bosses want answers. You have no time for a perfect fix.

Someone suggests a patch. You agree to clean it up next week.

The patch works. The crisis ends. You move on.

Now the temporary fix starts to become permanent.

Many think bad choices create technical debt. Often, good choices under pressure create it.

The fix was practical. It solved the problem. You slept well.

Then nothing happens. Priorities change.

• New features take priority.
• Other bugs appear.
• Cleanup tasks stay in the backlog.

Eventually, the patch becomes the system.

New hires see the patch. They think it is the correct way to build.

• Documentation mentions the patch.
• Dashboards rely on it.
• New features use it.

A temporary fix is now a core part of your code.

These fixes rarely break things immediately. They work well enough.

Years later, you try to remove it. You ask if anything depends on it.

Nobody knows the answer. Deleting the code feels risky.

Shortcuts are not the problem. The problem is a missing expiration date.

Later is where permanent debt lives.

Source: https://dev.to/omieee_24/why-every-quick-fix-eventually-becomes-a-core-dependency-5g69