[rusticpenn]

That is basically an example of sunk cost fallacy. Yes, those bug fixes are important, but its easier to find them and fix them again in a tool with proper architechture. The idea is to run the original and the redesigned code parrallely and find the differences in behaviour and fix them.

We recently moved from a heap of matlab code which was started with a student project in 2001 to a huge tool used in the industry today to a new implementation in C++ and python. It has been a huge sucess with our customers.

[mattmanser]

It's not a sunk cost fallacy at all, sunk cost is throwing further money at something that already failed. If the code is being used, it obviously succeeded. The product works. Otherwise it wouldn't even be worth rewriting.

The reason why people warn against rewriting is that it's a risk, a gamble, and often a conceit by the programmers. Programmers will also often spectacularly underestimate how hard a full rewrite will actually be.

You're taking something that works, and attempting to recreate it. You can find lots of examples where rewrite projects went spectacularly wrong. A commonly cited example was the Netscape rewrite (which killed a hugely successful company).

Your gamble paid off, but it's almost always the worst decision you can make. There's even examples in this thread of when rewriting goes wrong.

[rusticpenn]

Of course it depends on several factors. In our case, we were having a mess of spaghetti code, which crashed at important moments and there was no easy way to locate the issues. Sometimes, when your code required prayers and sacrifices to appease the gods and devils, then maybe its time for a rewrite. However, there are programmers who just want to rewrite because that think the old architechture is bad , when it is mostly fine.

[goto11]

But the forces which caused the current code to end up in such a sorry state will still be in force and cause the rewrite to end up in the same place.

If you have reason to think you can do better this time - e.g. the team have learned how to avoid unexplainable crashes - then you could apply this knowledge to fix the issues in the current code, which would a much less risk and less time.

[rusticpenn]

In our scenario, The tool had no requirements. A student project did something which a team found useful and saved money. More students were given similar projects. Then an engineer comfortable with coding glued the code from all these students. This happened for 17+ years (converting several person months of work to few hours). The team lead for this team got promoted to a very high position in the firm and he hired a software team to redo everything with coherent code.

For us the first project acted as requirements analysis. In most cases bad software is mainly because of lack of proper requirements. In hindsight, its easier to make complex tool coherent.

[goto11]

It is not "sunk cost fallacy" to not wanting to fix the same bugs twice!

[rusticpenn]

I think the word "bug" is not correct in this context. If a rewrite of the software contains the exact same bug, then it means that the requirements were not well defined.

[try_again]

There are certainly situations where that can work well, but there are also many instances where running two solutions in parallel is anything but trivial and adds another layer of complexity. Possibly to the point or multiplying the costs of the rewrite. I've been part of projects where that exact scenario occurred.