No one is actually arguing that worse is better. It's just a catchy title. A more accurate title would be "worse is faster than better, and being fast but mediocre is better than being slow and amazing."
Worse is better makes the observation that doing right thing slows you down. Often, an ok solution is much quicker to get finished than a great one. And it concludes that the projects that prioritize getting stuff done over code quality will suceeed.
Would facebook be as successful as it is today if it had taken longer to ship features, but maintained higher code quality? Who knows.
But the intuition in worse is better, which matches with my own experiences, is that making that trade off would have cost Facebook, as other faster moving projects closed the gap.
I agree with you that it's sometimes good to focus on getting things out the door fast instead of the code quality behind it. But surly there must be a point when the pendulum swings back and you should switch focus to quality. I would argue that Facebook have definitely reached the point where they own so much of the market and with their infinite resources they should be able to ship things with good code quality. Sooner or later the costs of supporting all that crappy software will make a dent even in Facebooks chest of gold.
They have written their own PHP interpreter haven't they? Thats a pretty good indication that they left some things too late. Saying that, if they have the resources where that sort of decision makes sense, then its probably not going to be too much of a dent in their pot of gold.
As you said, I just don't think anyone can know that alternate history.
It's very possible that a better architecture would have allowed them to move quicker and make more changes without breaking as much stuff. It's possible considering features before haphazardly implementing them would be beneficial overall.
Nobody can really know that, and to apply intuition to what is an extreme outlier seems off.
Worse is better makes the observation that doing right thing slows you down. Often, an ok solution is much quicker to get finished than a great one. And it concludes that the projects that prioritize getting stuff done over code quality will suceeed.
Would facebook be as successful as it is today if it had taken longer to ship features, but maintained higher code quality? Who knows.
But the intuition in worse is better, which matches with my own experiences, is that making that trade off would have cost Facebook, as other faster moving projects closed the gap.