The case for a rewrite

Ok here is something people just have to accept:

• All systems must eventually be rewritten or they will die

Now the question of course is how you go about it. The best plan is to have a plan. Realize that as you build a system, you add complexity which means eventually your feature curve levels off. You'll know this is happening because features end up taking longer and longer to implement. Even if you add staff you only have a short term increase in development velocity and then the inevitable context switching starves them for work and your curve levels off again. In other words, your graph looks like this

So you either limp along taking ever longer to add new features or you plan for the rewrite. When I say rewrite it can be either a total rewrite, module by module, or some other way of slicing your system up. The point is some time goes by and basically all the code is rewritten. You may of course not tell your customers this as they panic easily but believe me it happens in almost every system. Some call it a major release and under the covers a new architecture and new code goes in and the version number gets bumped but what really happened was a rewrite.

The important thing here is to realize that the goal of your rewrite is to enable your system to keep a steep feature versus time curve for as long as possible. In other words, you are able to add features over time for roughly the same developer cost. Programming methods, frameworks and architectures advance so they all help you to manage complexity. This enables you to continue to add features without so much technical burden and unintended side effects. Also important is to realize your rewrite will have 4 phases.

Phase 1 - This is the start of the rewrite and here everyone is happy. You take the best parts of the old system and port them over. There is no old code so things just fly.

Phase 2 - Ok here is where you need to have guts and stick to your guns. You remember all those nifty frameworks, new architecture, new build tools, etc. All those  help but they have their own learning curve. You'll bump into it here. Things slow down, management gets antsy. Hang in there.

Phase 3 - The curve picks back up again as everyone understands the new system and becomes more efficient. Productivity gains from the new architecture and tools really start to come through. If you have chosen wisely, your much better off than with the old system and hopefully you can maintain this development velocity for many years.

Phase 4 - The inevitable happens and you finally hit the wall on your system which by now is the (new) old system. Time to start thinking about the next rewrite.