The Importance of Refactoring
“If it’s not broken, don’t try to fix it” the old adage goes, but when it comes to software engineering at least, this is poor advice — at best.
Anyone who has worked more than a few years in software development knows that one of the hardest sells is convincing your boss to allow time for refactoring and cleaning up the code. On the surface it may seem like a reasonable stance — after all, no project asked for the change, no customer is paying for it — so why would you waste time on it?
Why indeed should you refactor, if leaving the code as-is doesn’t cost you anything? Because the code that’s “not broken” is costing you, you just haven’t noticed it.
The truth is that just like things in the physical world, code also needs to be maintained. It may not degrade and wear as physical objects do, but hidden in any piece of code are bugs no one’s found, bad designs no one’s bothered to correct, and potential improvements just waiting to be discovered.
I’ve lost count of how many times I’ve been introduced to codebases that for the main part have remained untouched for years or even decades. The old faux-truth of not fixing what’s not broken is embedded deep, and hard to shift.
I think a large part of the blame lies with the all too common project-financing model, where all resources for…
