Rebuilding our tech stack for the new facebook.com

And we forgot about it while developing it, this is just common mistake in product management, when projects are not iterative, things are so long, that you even forget why you are doing them

It's easy to guess what happens under the hood:

"Legacy" programmers implemented working solution.

A newcomer comes into the company, doesn't really give a shit about the company because he is #XXXX, follows textbook processes, has a very nice pay-check so no pressure, and decides to rewrite because "code sucks".

A second newcomer joins, still no pressure, because he knows he will get his pay-check. Tells his manager that he cannot work without refactoring (it's not true).

10 programmers later, you refactor code instead of producing features. You can do that for all your lifetime.

To their defense, the FB initial codebase from the time of Mark Slee or Philip Fung was not a gift but because they had pressure to make revenues they were trying to do what was right.

When you have 10 years of positive iterations regarding product experience and user feedback, revamping everything in a big bang boom is a terrible idea from both engineering and product perspective.

Sometimes, full revamp are positive because the initial product sucked, but when you managed to onboard a billion user, it's dangerous to change their habits if you aren't 100% sure it's an improvement.

Here, we have PO/PM pushing for change, for whatever reason (engineering pressure, or they get a bonus if they deliver the product, etc). Same story with all the Google Messengers.

It's a structural problem and little more: the website (and app) is their main money-maker, so they're going to give it a disproportionate amount of resources.

Imagine you hire ten thousand people to lay one railroad track. [note; see end of post] If any single one of them doesn't contribute directly in some way, you'll fire them. This seems kind of strange, doesn't it? Sure, it probably requires more than a single person to lay a track. But ten thousand people to lay one? How is that supposed to work, mechanically? This would be enough to warrant shareholder revolt.

Now, the railroad track gets broken a few hundred times, maybe they hammer it enough to make it twice as long, whatever. It now no longer resembles a railroad track. Certainly no train could go across it. Send a few hundred people to go ask the managers of this project for a replacement track. Okay, we're now at...maybe a tenth of people having contributed? Repeat this process until everyone's contributed. Maybe the manager gives different groups different materials for the track to fuck with them, whatever. But somehow, every single person manages to not get fired.

What's the outcome look like? You have a single railroad track, probably not even well-fit for the job (sparks fly whenever trains run on it; maybe it causes them to tilt, so on), but it's laid! And ten thousand people are employed!

It's the same thing with a website. You can't put a terabyte onto a user's device every single time they load your website; you just can't. So you have a window of performance you have to hit. Between ten thousand people trying to have things thrown onto user devices? Good luck making anything resembling 'decent'.

It's the same problem that Dave Zarzycki noted in his talk about launchd[1], but worse. Instead of 512 megabytes shared between some random abstract parties you can basically ignore, it's [note]: This is the appropriate comparison here; at the scale of 'Over ten thousand people working on one program', it's grunt work, not art, science, or even programming. There's a word for implementation-grunts that's fallen out of favor in the past few decades: coders. This was seen as distinct until recently.

[1] https://youtu.be/SjrtySM9Dns?t=255