>Typically this is a death knell for a software project

Only according to a popular, but not exactly scientific, old-wives tale of an article by Joel Spolsky.

Lots of commercial apps that had end-to-end redesigns with improved engines (DAWs, NLEs, etc), and did it just fine.

FCP to FCPX is one example, Cubase circa SX era, lots of others...

Even Joel's example, Firefox, is only viable today because they did many redesigns. If it was still the old Mozilla era-4 codebase + cruft upon cruft, it would matter even less.

I work on a project that was a ground up redesign, except for one small (but one of the most important features for our customers) that was ported to the new system. In the years since the team working on the ported part has been given time to make their code better. I have concluded that we could have in place refactored the old code to the new system and been fully functional the whole time for much less cost.

The new system is clearly better than the old one. If we had refactored in place we wouldn't have the same system as we have now. With the benefit of hindsight, I can now see some places in the new system that are not working as well as hoped and we are working on a plan to refactor those parts in place to something better.

Wasn't Joel's example Netscape Navigator, not Firefox?

It's basically the same thing. The big Netscape rewrite was from the 4.x code to the 6.x branch; the 6.x branch was what was released as open source, and when the decision was made to build a UI that encompassed only the browser and not the mailnews code, the resulting application became Firefox.

Yes, but Netscape Navigator got rewrote to Mozilla who eventually turned to Firefox. So same thing -- I referred to his example by the (current) name of the rewritten product instead of the name of the name of the original product that got rewrote.

The reason behind this wisdom is that it's easy to suggest a rewrite because you think the current code is too complex. You suggest a rewrite because you cannot grasp the current code. If that's the case, then I think the mentioned wisdom more or less holds up. However, it's also possible to understand the complexities of the current code, and still suggest a rewrite. Then the likelihood of a success is much, much bigger, I think.

I'm not 100% sure, but I'm under the impression that imdb.com pulled off such a rewrite a couple of years ago.

I can think of a few opensource projects where it has not been, and have been involved in a few such successful projects professionally myself.

It's certainly not something to be taken lightly or by people who don't understand the intricacies of the original system (Chestertons fence) but I think people are sometimes too reluctant to do this sort of thing.

> Typically this is a death knell for a software project -- however well-reasoned, well-intentioned, and well-planned.

i've watched this cliche doom more projects than the actual attempts at rewriting/rearchitecting.

midwit managers crying "oh engineers always want to throw everyone else's work away" have basically banned redoing anything, no matter how dire the situation.

Your quote specifically uses the word "rearchitect", not "rewrite". It doesn't imply throwing out all existing code, which would indeed be madness.

I think 'rearchitect' should be interpreted as 'redesign the UI', not as 'start from scratch'. Most big changes seem limited to the UI (and done as part of a Qt -> QML migration). And it looks they'll do even those piecewise:

> In order to get the release of 4.0 out as fast as possible, we will be porting over many of our less used interface elements and dialogs directly from MuseScore 3. The plan is to gradually replace these with redesigned versions (built in QML) in subsequent releases (4.1, 4.2, etc.).

That doesn't sound unreasonable to me.

> Typically this is a death knell for a software project -- however well-reasoned, well-intentioned, and well-planned.

beh, that's what we did for at some point for ossia.io and it turned out very very well