Hacker News Reader

Comment by aaron-lebo | Hacker News Reader

But it's not better, it is worse as clearly put forward by this article. ;)

We shouldn't attribute Facebook's success to poor quality code, unless we really believe that 429 people working that that slow sluggish app is productive. Do you?

Maybe Facebook would be in a better situation than they are if they had a firm foundation? What happens when a competitor comes along and knocks on their door? That mess of code becomes an anchor.

They succeeded not because "worse is better" but because ...they succeeded, maybe because they had the greatest social network in the world to expand within, or because of some other reason we don't know. But they didn't succeed because of worse is better, they succeeded in spite of it.

View on HN

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.

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.

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.

> Do you?

It's written between the article's lines, so to speak, but it seems like the bad code quality was generated in part by FB moving at a very fast pace. I think they wouldn't have been as successful as they are had they chosen a slower path with more "correct" code and architecture.

> What happens when a competitor comes along and knocks on their door?

They successfully managed to "eat" and integrate both Instagram and WahtsApp, both worthy contenders at the time, and they're now on their way to stealing Snap's lunch, so they've proved to be pretty resilient on this front. Not to forget how they successfully kept Google+ in check.

how would that success have been different if they had used different engineering practices?

a big part of their success was delivering results... if they hadn't quickly crapped everything out of the door, how would facebook look today?

Agility trumps code quality. Stability can be addressed downstream (which Facebook does with heavy testing and rollouts of changes). Code quality problems or not, Facebook has been more stable than its competitors (MySpace, Twitter, etc.) and faster at pushing out changes.

Is it more stable than those two?

I can't see the point in Twitter (neither could a number of my colleagues when it was mentioned at a dinner a couple of weeks ago, none of them used it).

MySpace was a genuine competitor, but allowing teenagers to style their own HTML made for some horrendous pages.

Facebook had a nice clean interface, as well as network effects. I was signed up to a similar service at the time - HighFive I think it was called, but the network effect was what snowballed with Facebook and led to its success. At the time I didn't see either one being better or more stable than the other.

Reply on news.ycombinator.com