re: A big rewrite VIEW POST

VIEW FULL DISCUSSION
 

You should avoid complete rewrites at all costs. Try to find one small aspect in your legacy application and rewrite that. Then integrate that newly rewritten part in the old system. If you have integration tests for the old system, you can use them with the new code.
This has several advantages:

  • You dont have to maintain two systems, with rewrites it is hard to judge how much time should be spent removing bugs in the old system.
  • You can run the new part A/B style to check if it is performing as expected
  • Your legacy application can benefit earlier from new code

The downsides are that you cannot do this if you basically need a completely new system

 

Yeah, I feel a complete rewrite should be the last resort. It made sense in the example I linked to because they had unmaintanable software with no tests and they were going to run out of money.

Usually in a more established company when you accrue tech debt, you can rewrite/refactor in steps as you said.

 

This is pretty much the micro service mantra, driven by a need to uncouple change in different areas of a system so the team can keep up with unpredictable demands (or at least only short term predictions), without throwing everything out from the monolith on day one. Martin Fowler (him again!) describes this as evolutionary architecture.

code of conduct - report abuse