It’s the same old story. You got a ticket, and like always, it has its complexities and gotchas. While working on it you find yourself blocked by some legacy code. You start digging into the issue and boy oh boy it is a mess. The deeper you get the greater the anxiety. “I have to refactor the whole thing!” you think to yourself. You’ve got trapped in a whole different issue and forgot all about your initial ticket! You see that you are going to miss your estimations. You report to your PM who has no idea what the hell you are talking about but has to accept your take disappointedly. At least you raised the flag on time.
“This codebase sucks, they should fire whoever wrote that code”, you think to yourself (just before you discover it was you, only 4 months ago).
This is the tragedy of the over-engineered codebase and sometimes there is no other way but to refactor the whole damn thing.
However, many times, the truth is that there is another way, and we are missing it because we convinced ourselves too early that a large change is needed.
We looked at the code, got disgusted, and decided that it was not good enough, and to solve our little problem, we had to “solve the problem from the root” and fix it once and for all.
And you know what? It might be true! There might be a deeper problem, and fixing it will solve your little problem out of existence. And you know what else? Your clients don’t care! Your product works just fine as it is and they want this little extra feature right now, not in 6 weeks.
So you can leave your ego aside, take a deep breath, get out of the tunnel vision, and ask yourself a simple question: “Is this big change necessary? Is there a simpler way to solve this problem?” And you might find out that there is. And you might call it a hack, and you might even hate it. but it will work!
So instead of pushing the deadlines, and disappointing your PM (and your clients BTW) you can open a “refactor it later” ticker, commit your “hack” and help the business grow.
Furthermore, If you work in a good enough team, and this deeper problem is still nagging, you will get the time to work on your “big fix” and refactor the shit out of this codebase! But this time with enough time and focus.
If you found it useful, I will be happy to hear about it :)