Comment by abustamam
10 hours ago
When I was pretty early in my career, I inherited a legacy project from the CTO who didn't want to maintain it anymore. We decided as a team that I'd just recreate the project with a modern tool chain.
A few weeks later, the CTO looked at my work and asked why it was missing xyz features from his legacy project, saying that if I'm gonna take a project and rewrite it, it better be at least as good as the old project.
It was a pretty good lesson for me to get early in my career, and I've carried it with me ever since. Don't break or rewrite that which already works.
It's evident that no one at Google ever got that lesson.
NB: I know Google definitely has other reasons for acquiring and killing off Bump — they were probably building a competing technology that was shitty and bump was doing it better and sooner than them so better to buy and kill than to make their own product better. But I think my the lesson from my anecdote still stands from a purely product point of view, and I feel like it should make business sense but apparently you can make bad micro business decisions as long as you can convince shareholders they were good macro business decisions.
I changed my thoughts on rewriting after reading this:
https://www.joelonsoftware.com/2000/04/06/things-you-should-...
PS: I just realized this article is older than some of the people here.
I would rewrite if the alternative is maintaining bad code for a long time. But yeah, it’s best to be pessimistic. And be really careful about changes. There are books written about the methods to use.
The lesson I retain from a similar endeavor is that you should document all the usecase of a module or a project before rewriting them. And that task can be as exhausting as formally verifying the module.