I’m probably the last to find this excellent piece on Jens Schauder’s Blog called Don’t Rewrite Your Application. It’s not only worth reading, but also thinking about it and memroizing it. There’s almost never a really good reason to rewrite a reasonably-sized business application. The effect will very often be a the loss of a lot of money and probably never an application that is substantially better than the one it replaces:
- Whatever you might think of the code base and the developers that created it: They weren’t stupid nor evil. So chances are the results of your work will look just as ugly in two years from now.
- You don’t know the requirements: Part of the reason legacy code bases are ugly is that requirements change. There is no reason for you to assume this won’t stop.So chances are the results of your work will look just as ugly in two years from now.
- You don’t have the time: As long as the rewrite isn’t done, you’ll need to maintain and probably evolve the current application. If it is of any importance, you can’t ignore it for the months to come. If you can you should do so without wasting your time with a rewrite.
So true. In the Smalltalk world, we’ve seen all sorts of craziness in that field. Some customers spent literally millions of Euros into this lesson. Here’s a possible solution:
Instead of rewriting the application refactor it. Learn to properly estimate the effort needed for implementing new features in a clean way. Add some time to make the code immediately around that new feature a little cleaner as well. Use that as estimate. This way the application will become a little cleaner with every update.
Boy, how right he is!
If you know the requirements of your system, still have some skilled developers on the team and need to move the application further, it’s almost always better to invest in existing know how and the team to improve their skils in techniques like Refactoring, Unit Testing and Code Management. Combined with Continuous Integration you can accomplish several things:
- Improve an existing system with new features in little time
- Lay the grounds for easier addition of features in the future
- Come back to the pace of innovation that your project once had
- Save a lot of money and frustration (and if you are a CTO or in upper management probably even keep your job and feed your family)
- (Re-) Motivate some of your most valuable team members who’ve lost their believe in a future of their projects a long time ago (you should NEVER underestimate this aspect!)
- Motivate new staff to come to your project as it promises to be fun, effective and respected within your organization (Have you ever heard or said the sentence “we can’t find Smalltalk developers”? – maybe it’s your fault because you scared people away from the project or technology for years for no real reason…)
- Surprise your users with new features instead of apologies for not delivering
- Have fun!