> Also, a good lesson from Facebook: instead of rewriting their PHP codebase, they extended the language by creating the "PHP++" language Hack (along with the HHVM runtime), and incrementally changed their codebase to take advantage of Hack

I agree with most of your comment, but I don’t think this part generalizes. This isn’t feasible for most companies unless you’re operating at Facebook scale.

I agree it doesn't generalize, but I don't agree that it's because of "scale". It doesn't generalize because not every company should write its own language (and can't hire good enough engineers for this). And, fortunately, most "legacy" codebases aren't in "bad" languages, so there's no need for this.

Afaik, the team that did Hack/HHVM at Facebook is ~5 people. I don't think you need scale for this (the rewrite of the code itself is not a scale thing, the codebase is usually linear-ish in the number of engineers).

My point is: instead of doing a rewrite, be inventive and avoid it, and this is a great example.

What Facebook did amounts to rewriting PHP itself though.

And this made sense for Facebook because it probably would've taken 100s of engineers to rewrite all their php.

Also, not every company could hire the 5 people needed to do their own version of a hack/hhvm project. But at some point it makes sense to find those people instead of rewriting in an unrelated language

It’s not about how many engineers it takes to make a new programming language or runtime.

Facebook has the scale to invest in creating tooling, IDE extensions, core libraries, documentation, training, test frameworks, bindings, etc for a new language that they create. They also have the organizational scale and career development to make it worthwhile for an engineer to learn their proprietary language.

This doesn’t apply to most other companies.

A competitor can also eat your lunch with a greenfield product if you are unwilling to move on from your legacies.

I guess “rewrite” is bad, but “reinvent” with experience from the former system shouldn’t be shied away from. Incremental improvements might only take you so far before competition overtakes you.

I agree with this 1000%.

The only point I'd like to add is that incremental rewrites often have long-lasting value in terms of a culture that emphasizes continuously paying down tech debt.

far too often I have found rewrites, which in many cases involve moving to new hardware and possibly OS, tend to drag on because those involved do not know all the touch points of the current systems and also fail to properly count the investment other teams have in making connections to the original systems.

I have even seen them done to bypass a management/development team that was in disfavor with the company leadership. In effect, put together a new platform with new leadership.

Let me guess: the only specification they had was the old code?

You say it as a negative, but in practice, the old code is the only reliable specification.[1] Written specs are never comprehensive enough. If you rewrite based off of specs, you're bound to have both bugs and missing features.

[1] Well, if the codebase has very comprehensive tests, that's likely better than the old code. But few projects have this.