When to do a software rewrite.

In general, don’t rewrite. But if you do make sure it is for a good reason.

Photo by Markus Spiske on Unsplash

I look for the one or more of these characteristics in the system to
justify a rewrite.

• Fixing a bug in one part of the system causes a bug to appear in another
  part of the system. This means the two parts are coupled in some way. If it
  is not a part of a planned interface, that means the coupling is subtle and may be impossible to find.
• The technology has changed sufficiently to justify a rewrite. One system
  I worked on had been in service for 20 years. It was written in C and required millions in maintenance and test. It required one year and one million dollars to adapt for each new set of requirements. I had in 20 or so processes that had to be on 5 to 6 machines. Each machine costing $6000. Using Java as the replacement system cost $3m once but cut the time to adapt and test to one month (of which three weeks were training) and $20,000 and two Linux boxes at $3000 each. It did not require any special purpose hardware.
• The requirements have sufficiently evolved to make it more cost-effective
  to start over than to modify what is in place.
• The performance of a scaled system can only get better by faster hardware
  and not more servers.