You start working on a task. There's a deadline on you. You code whatever you think is good enough to achieve that deadline and get it deployed to production.
While working on it, you knew instinctively that the work you submitted wasn't the best quality but it will do "for now". You justify it to yourself that your work could've been better, but you had a deadline over your head.
You tell yourself that you will later refactor it, to improve the quality. But not now, because there are other tasks to be completed under more deadlines.
This cycle continues, and you get to a point where the refactoring stack has gotten so large, that you get exhausted just looking at it. You think about submitting a request to the lead, but you get rejected.
Because leadership and management don't see the ROI in it. The code that you delivered works for now, so why bother spending resources on it when you can get some other work done which is higher on the priority list?
No one can justify who's in the wrong here. Because, you can always refactor your refactored code. There's always room for improvement, no matter what. And that too, in an environment where requirements are forever changing, you can never really catch up to your own refactors.
Corporate doesn't want their resources spent on refactors, because it works, for now. So what they wait for, is a downtime complaint. Only then, they can allocate resources, given that it holds any priority.
It's why many times when we face issues and talk to customer support, our queries take time to get resolved.
Refactors can save time and money in the long run, but it lacks ROI which is why it always gets looked over.
Where do you stand on this? Let me know in the comments!
Top comments (0)