We’ve all experienced this: you’re working on some code … probably code that was written a long time ago … and you realize that, with all the experience you’ve accumulated since the code was originally written, you could re-write (or refactor) the code so it would be much better.
The question is … how do you justify a refactoring of the code?
It’s been my experience that TPTB will rarely approve the effort involved in refactoring simply based on making the code base easier to work with, manage, and maintain. They want a concrete ROI for the change.
Refactoring provides many gives you the opportunity to enhance the code so it’s …
- More modern code.
- Easier to maintain.
- Easier to understand.
- Creates a standardized interface to the code.
… there are, however, many pitfalls …
- Takes a lot of time.
- Needs to be re-tested completely.
- Risks breaking other code that interacts with the original in unknown ways.
I’ve worked on a number of projects recently where the code base would have benefited greatly from refactoring. And, we had every intention of doing some level of refactoring, but in the end we had to settle with just writing an adapter procedure to the existing code as there just wasn’t enough time in the plan to fully refactor.
Our wrapper could have great promise to be a primary entry point to well written, highly structured, easily interfaced, code … but I doubt it will ever come to pass.
So the question is still there … how do you go about justifying a code rewrite?