Someone on Reddit asked for experiences on when to re-write an application as opposed to incrementally upgrade it. As I mentioned last time, I wrote a very long comment as a reply, and Reddit’s API did not accept it. I lost the content. Now that I’m less outraged about this, I’m going to re-write it today.

The specific thing OP wrote that I choose to treat as a prompt was this one:

I’m not really seeking an answer on whether or not we should, I just want to hear any lessons learned from folks who have been in a similar situation. Thanks for the input.

I have learned a lot of lessons about both approaches. Today, I’m going to share what I learned from full re-writes. Next time, I’ll share lessons from incremental updates to old software. I may make updates to this post also - I am in the middle of a few re-writes right now.

What I have learned about full re-writes of existing applications:

• The total rewrite will take longer than you think. Whatever your current estimate is, double it.
  • A lot of time will be spent studying what the current application does, in an attempt to understand that behavior well enough to replicate it.
  • You will need to spend additional time thinking clearly about whether or not all of that behavior should be replicated.
  • There will be some necessary feature of the application that will be very difficult to implement in your new stack, which is not difficult to do in the old stack. You do not know that that feature is yet.
  • Your developers will come up with new, worthwhile improvements to make. They can quickly bloat the scope to well past what it needs to be.
  • Any increase in velocity from working in new, better technology will be eaten by the activities above, unless the application is trivial, or project scope is managed aggressively.
• Re-writing the application from scratch in order address security vulnerabilities does not ensure that you will end up with an improved security posture, because the security of the new application will not be known until it is finished and evaluated by someone else.
• Stakeholder buy-in is essential for a successful re-write.
  • If you stop working on features in the old application to do the re-write, the pressure to finish fast on the re-write project will increase massively.
  • If users like the old application and do not want to use the new application, they will find ways to delay the project as long as possible so they can keep using the old application.
    • They will invent new requirements that the old application does not meet, and claim they are critical before migrating.
    • They will nitpick every aspect of UI, simply because that is the easiest thing to do.
    • If you make any of the changes they ask for, they will ask you to change them back, and act like they didn’t ask you to make the change in the first place.
    • Alternatively, they may simply act agreeable to every change you make and be very polite all the time, not asking for anything. That’s because they think they can bypass you to prevent the deployment of the new software.
• Because you’re replacing the old application in one shot, your first production release and cut-over will be big, dramatic events unless risk is managed carefully.
  • Make sure you have a testing environment to deploy in before trying to go to production.
  • Make sure that you actually practice the deployment.
  • Come up with a rollback procedure if you need one.
  • Even if you have a rollback procedure, you should be prepared to fix-forward instead.
  • Running the old application and the new application side by side can mitigate some risks.