Ask HN: Do you know any stories of successful large rewrites?

[darzu]

I'm trying to convince my manager that it's worth rewriting large parts of our web app. He's skeptical and listed some examples of failed refactors. And indeed I've heard many cautionary tales over the last 10 years of my career. But sometimes it's got to be worth it and the outcome is positive. He asked me to find examples of rewrites gone well.

Do you know any?

[db48x]

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.

[PragmaticPulp → db48x]

> Now that I've learned Go, it wouldn't be my first choice.

Funny you mention that. I worked at a company that rewrote a project in Go when it was the hot language. Go helped us solve the problems from the old language, but it introduced a new set of problems.

Later, someone suggested we re-rewrite the project again in Rust. Obviously, that didn't go anywhere.

> All I need to finish the task is about 4–6 months of free time…

4-6 months of programmer time is not cheap.

You can buy a lot of faster hardware for the price of tying up a single programmer for half a year.

[db48x → PragmaticPulp]

That is frequently true. However, when it is your customers buying the hardware then it's a bit rude to be wasteful. On the other hand, the repository conversion that GCC did was an extreme case. Their SVN repository had 287k commits in it, and I've only heard tales of larger ones.

[PragmaticPulp]

> 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.

[pedalpete → PragmaticPulp]

In addition to this, there are all the horror stories of re-writes being a waste of resources. I've done it myself, and wish I hadn't.

Having said that, I think this is one of the great benefits of micro-service architecture. You can re-write piece by piece as you add functionality or create a measure of improvement. But don't use the "we need to write this as micro-services" as an argument.

You say "re-write large parts", so I assume that means not the whole thing, and not a new language. If that is the case, I'd suggest tackling the "re-write" as a piece by piece upgrade rather than a re-write, and look for a business case for each component you plan on re-writing.

The engineer wants a beautiful system, the business wants a system that works. The business pays the engineer. So buy "selling" the business the benefits of specific improved functionality, you may get a new beautiful system.

Is there a part of the system that is particularly expensive part of the app from a services (DB, API requests, etc) stand-point? Can you quantify for the business the benefit they'd get from re-writing that part of the app, and the cost savings they'd expect to get?

If you're close with the design team (which I hope you are, or suggest you become), are there business goals they are designing for which would allow you to sandbox a part of the app to be re-written? Do that 20 times, and you've got a new app, and you didn't do a 're-write', you just kept adding great functionality and cleaning up as you went.

So, I'd suggest getting the idea of a 're-write' out of your head, and instead approach it from a "how can we improve this tiny piece of the app while pushing the business forward".

[username90 → PragmaticPulp]

Rewrites succeeding is the expected outcome, only articles of when they resulted in a catastrophe will bubble up.

Typical scenario: A team rewrites their code, they succeed, nobody notices since things are still running, end of story.

[giantg2]

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.

[2pEXgD0fZ5cF]

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/

[psychstudio]

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.

[codingdave]

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.

[hkarthik]

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.

[sethammons]

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.

[username90]

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.

[killtimeatwork]

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.

[ohiovr]

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

[ohiovr]

Blender 2.8 I think was a rewrite.

[Tomte → ohiovr]

Certainly not. They revamped the UI, but they didn't rewrite the program itself.