Why rewriting a code from scratch can be a terrible error?

This week, during my research, I found an old blog post from Joel Spolsky named “Things You Should Never Do, Part I”.
The post is 20 years old but is still relevant today! It explains why rewriting a code from scratch can be a terrible error for a company.

For me, rewriting a code from scratch is a double or nothing bet. It can be productive in some special cases (Very old code base, new standards, revolutionary technologies, etc.…). However, in majority, it is inefficient and counterproductive for commercial usage. We can dispatch the common issue in two parts: Architectural and Performance.

Concerning architectural issues, they can be fixed smoothly. Time by time, I can modify an interface. This other time, I refactor a class during a development. And again, let us rewrite this single part which is slow!
Trust me, I applied this method during years on an old project. The result today is a code modernized and easier to understand compared to few years ago. First, modernize build tools. Then, refactor the code iteration after iteration is pretty efficient.

Concerning the optimization... Do you have a code which is not performant (slow, memory leaks, etc…)? Let identify the part and do not rewrite the entire code! A simple modification of the concerned part is maybe better for the commercial usage. Your code is immediately deliverable and productive.

Of course, some errors are hard to fix (Threading, shared pointer...). But I doubt it is a reason to throw it in the trash bin.

The code I am still ashamed of.

This post is a particular one. Have you ever been ashamed of your own code? In an ethical way?
I already encountered some questionable decision during my career.

You may know this well-known post from Bill Sourour: The code I’m still ashamed of.

The question of ethical in software is still important: There is a chance that during your career, someone will ask you to code something a little deceitful. This experience from Bill Sourour is touching and terrible. It reveals how you can code something unethical and why it is important to say “No”.

In my personal experience, I already encountered this. Fortunately, leaders were listening, and it was resolved quickly (Just say no and explain why it could cause problems). But I supposed it is not the case for everyone. Moreover, saying "No" is far more easily said than done. You could have terrible leaders which refuses to listen your concerns and stay the course.