Temporary Fixes Become Permanent Code

“I’ll fix it later.” You never did. Now it’s permanent. Every developer has said this at least once: “I’ll fix it later.” At the time, it feels harmless. You just need a quick solution to move forward. So you add a small workaround. A shortcut. A patch. It works. And then you move on. But “later” never comes. That small fix stays. Other parts of the system start depending on it. And suddenly, removing it feels risky. What started as a temporary solution quietly becomes permanent. Not because it was right, but because it was convenient. This is how complexity builds over time. Not from big decisions, but from small things we choose to ignore. Be honest—how many “temporary fixes” are still sitting in your code today? #programming #developers #codinglife #softwareengineering #debugging #technicaldebt #devlife

  • No alternative text description for this image

The real problem isn’t the shortcut, it’s forgetting to schedule time to come back and fix it.

Like
Reply

And somehow, those “I’ll fix later” parts are always the ones no one wants to touch again.

when you create temporary fix make decision when you will fix it (or at least make task for it), After just never remove this reminder or task until fix is removed. Sooner or later you will rewrite this functionality. All you need is self discipline or task management system where every one understands that tasks should not be thrown away. But any way most people who says I will fix it later, will soon say that this is fixed (without any actions). As saying costs 0 you just say and throw away. I hardly remember when I have this kind a decision where I could reach with my hands, I always try to do my TODOs before pushing to review. Very rare cases where my TODO contains issue that I created to fix this.

See more comments

To view or add a comment, sign in

Explore content categories