There once existed a application that was written in PHP before there were any decent frameworks available. For the backend of it (a large batch job) there was a decent architecture, but a horrible implementation. For the web interface, there was only the horrible implementation part. Since there were some open feature requests for the web interface, the obvious question came up: rewrite or refactor?

The application in question was rather old. As software tends to do, the code had corroded. Many different developers have worked on the system, and most of the code had been written before code reviews were part of the process. The environment of the system had changed: it was now talking to different systems, and a lot of business processes had changed as well.

In this kind of a scenario a rewrite sounds very interesting. You get to use all the latest shiny toys and can make a fresh start. You can completely skip the burden of understanding the existing code.

So, what did we do? We tried to make a path to the situation we wanted to go to, and found out that that was perfectly possible. All the individual refactorings are rather small, so there is no need for branching. This will save in the merging. (Yes, indeed, creating a branch is making a promise that you will reintegrate this with the mainline in the future.)

Plus doing a rewrite is like having the word “all” in a requirements engineering document. You suddenly become responsible for all the features of the application that you did not even know existed. Since this was not the youngest of applications, this was rather likely to happen.

So all in all we opted for the iterative improvements. Slowly changing one aspect at a time until we’ve arrived at the ideal state!