Do you know any?
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.
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.
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.
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".
Typical scenario: A team rewrites their code, they succeed, nobody notices since things are still running, end of story.
I can't give you the names. Even if I did, you wouldn't know them since they were all in-house systems.
- Old: https://github.com/jp9000/obs
Most software that's been around a long time is generally a Ship of Theseus.
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.
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.
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.