Do you know any stories of successful large rewrites?

I helped rewrite Reposurgeon. It was originally written in Python, and is now written in Go. In the process we shed all of the overhead from the Python interpreter, which sped the program up significantly. I made further improvements that cut the memory usage of the Go version in half (from >256GB to <128GB of ram for the task of converting the GCC repository from SVN to Git), and dropped the run time to about a quarter of what it was.

Now that I've learned Go, it wouldn't be my first choice. Around 70% of CPU time is currently spent in the heap scanner, looking for garbage to collect. Initial experiments with Rust show a marked decrease in memory usage and run time, and that's without any really tricky optimizations that Rust could make quite easy to do. Just the storage space used by all of the filenames in the GCC repository is a huge amount of ram, and in Rust a string interning system is quite easy to write. (In Go it would be impossible, though perhaps now that generics are on the horizon that will start to change.) All I need to finish the task is about 4–6 months of free time… or a grant, now that I think of it.

> Do you know any?

Generally, if you get to the point where you have to scour the internet to cherry-pick positive stories, it's not a good sign.

In these situations, you shouldn't be asking if success stories exist. It's a big world out there, so you're bound to find a success story somewhere.

The real question is how likely it is to succeed, and at what cost?

I worked at a company that did a somewhat successful rewrite, although it came at a cost. In retrospect, the rewrite helped us get rid of some problems we knew we had, but it introduced a large number of new problems we didn't see coming. It also cost us the better part of a year just getting back to feature parity with the original product. From a product perspective, that time would have been better spent working on new features.

I've seen significant sections of a system be rewritten. This is usually done as an upgrade - meaning we can sell the business on some new function/capability or reduced cost. It's much easier to do on the systems that are not tightly coupled, so you can replace whole chunks and flip things active-inactive, but I've seen it done even in tightly couple systems too.

I can't give you the names. Even if I did, you wouldn't know them since they were all in-house systems.

As far as I am aware OBS [1] did a complete rewrite:

- Old: https://github.com/jp9000/obs

- New: https://github.com/obsproject/obs-studio

[1]: https://obsproject.com/

In all my years I've never seen a complete rewrite (i.e. a "cleanroom rewrite"), but I've seen many systems and subsystems evolve over time (usually in the same language) which eventually, one has to ask "is this the same software?".

Most software that's been around a long time is generally a Ship of Theseus.

Sure - I spent a decade decommissioning Lotus Notes apps in various Enterprises. I did a ton of successful re-writes of small apps to more modern stacks. But the bigger and more complex the app, the worse the rewrites were. It was often better not to re-write at all and instead to start from scratch and re-solution with the business to determine whether they even the same app again. Often, those complex custom apps that were 10+ years old now have off-the-shelf solutions that worked better anyway.

I've also seen full re-writes of large complex apps work fine... if you are willing to dedicate an entire team to it for 2 years.

But if you are looking for a huge re-write done smoothly, easily, and quickly... I have no success stories like that, and recommend against trying it.

Uber rewrote its entire backend and both major mobile apps between 2014 and 2019. While there was definitely some reuse, we switched languages on several of these so there were direct ports as well.

It took a lot of engineers to do this while also launching several new business units and scaling to hypergrowth simultaneously.

So yes it can be done, but it will come at a cost and you need to be in a position where the business won’t fail if it takes a long time, or you can afford to run several concurrent legacy systems at the same time.

At Twilio SendGrid, we rewrote and re-architected our main services while increasing our scale. We went from stateful Perl and Python to now mostly stateless Go. It is very hard to do right. You have to find minimal changes that can have results compared for accuracy. It has literally taken us years to do so safely and we are still in flux. The change has been nothing but positive, but it is not something to take on lightly.

Did you write the app originally? If not assume that it will take you at least as long to rewrite as the original team took to write it.

If you are significantly more competent than the original team you can cut that down a lot, so if your manager agrees that you are significantly more competent than the original team it should be fine.

I've heard that one of the earlier versions of Oracle RDBMS (back in the 80ties) was a complete rewrite done a couple of super talented guys over a couple of years.

Netscape was open sourced but they did end up rewriting everything into Firefox. I don't remember the exact details.

Blender 2.8 I think was a rewrite.