Programmers love to claim that a program needs a rewrite. They are almost always wrong. They feel that accumulated complexity has lead to a program becoming unmaintainable and the only way to fix it is to throw everything away and start afresh.

They only remember what is difficult to change in the current program and not what is easy.

They don’t think about the fact that a lot of the accumulated is there for a reason, and the current code base contains heaps of real-world testing and poorly documented knowledge.

Programmers love the feeling of a new program, because a new program is without bugs. The fact that the new program lacks 100% of the existing feature set is only viewed as a minor hurdle.

Such projects always take longer than expected, run over budget, and take a long time of playing catch-up to the existing and evolving feature set. After the transition finally catches up (if ever), you’re stuck with something that’s likely to be just as complex as was there before because the complexity was reflecting that of the real world. With the new program, there will still be (possibly different) things that are complicated to fix.

Until the day some genius suggest scrapping everything for a complete rewrite.

The right solution is almost always to adapt what is always there, because at least you don’t start our from zero and can focus on improvement and adapting to future reality without also having to play catch up.

#itsananalogy #cantspellanalogywithoutanal