So you want to rewrite or re-factor your application
Why Code Rewrites Don't Always Work.
Give an engineer some code and one of the first things crossing through the mind of some engineers is, "Should I rewrite or re-factor that code?". The logic being that the new version will be ultimately be better in some way than the original.
However simply rewriting or re-factoring an application doesn't always warrant the effort you put in. The rewrite version may generate new, but different bugs. As well as include some of the old existing bugs. The new version may ultimately take far longer and cost more than the original. It could even run the risk of missing its time to market or not really meet users needs. I use the term 'time to market' to cover open source projects as well.
So what should you do if you want to rewrite an application, or one of your colleagues is planning on a great rewrite project and you want to convince your manager that they shouldn't just say no?
Well, I have some tips and techniques that may help. I've been developing software for over 20 years, most recently at SpikeSource. I've seen the good and the bad and formed some of my own thoughts over the years. I'm interested in your thoughts too!
Why does an application need rewriting?
First what is a rewrite? I use the term rewrite and re-factor interchangeably although there is a difference. A rewrite normally implies additions, deletions and corrections to an application. A re-factor is a change that should leave existing interfaces unchanged. In this context both apply but more typically a re-write is where most of the issues appear.
To find out why an application needs re-writing, it really helps to find out what happened during the original development. Ultimately many projects that now require a rewrite, experienced one or both of the following.
Case 1. Short of time and was under-resourced
Case 2. The project was breaking new ground or was experimental
The results of these constraints is that in the first case the project is very likely under-tested or even untested. In the second case the project is more likely to be under-specified or unspecified, especially if the end users are unknown.
Steps to make the re-write a success
Case 1: Short of time and under-resourced
1) Bug fixes and hacks that clutter or make code messy
2) Bug fixes that don't have test cases
3) Documentation if it exists, doesn't match the source code.
The first question you should ask is this. If the original author didn't have time to complete the project what has changed, is there more time now?
Does the application have a large mature installed based? The risk/reward ratio on rewriting this type of project is going to need significantly higher development costs to mitigate those risks and make the project a success.
Were the tests hard to implement or run, for example i18N and GUI tests are often expensive and test optimizations are often made.
If you do go ahead, spend time to revisit the design and make the specification complete. Backfill tests to validate the current behavior. Those hacks may initially appear like they can be re-factored but without the tests to verify changing the code may introduce a new bug. By putting more cost into validation the rewrite has a higher chance of succeeding.
Case 2: Experimental
1) Specification will be incomplete, or not reflect the final product
2) Tests, if they exist do not match the end user experience as there were no end users
Again re-write the specification completely before starting.
Try and extrapolate test case scenarios through initial bug reports.
Finish use cases and plan to spend a larger effort on test cases before starting coding
Rewriting a project should never be undertaken lightly. The difference between a rewrite success or a rewrite failure can be a matter of a few bugs either way.
Ultimately don't repeat the mistakes of the original author, especially if that original author was you.