Hacker News Reader

Comment by cft | Hacker News Reader

You are talking about either business complexity or the critical minimum amount of money that is necessary to enter and dominate a market. I am taking about the engineering complexity.

They could not be created earlier for the same reason why Hollywood could not have been created in the 17th century: there was no motion pictures technology or modern internet distribution channels. But none of that tech has to do with Hollywood.

The engineering complexity of Airbnb is in the ARM SOC and in the GPS constellation, but not in their app.

View on HN

It isn't necessary that a Unicorn must create something technically sophisticated and intricate. Airbnb is a service, not a tech product. This is an apples to oranges comparison.

There are plenty of startups that work on challenging engineering problems (though I'd have to google for the Unicorns who do that).

Then we should call it "Service Valley" and the people doing this "business men", not "Silicon Valley" and "software engineer".

Even comparing the engineering complexity of what Google does, and what Airbnb, Uber, etc do is impossible. Many large unicorns are doing nothing new, or special. They are only clicking existing technology together. Which means they are very easy to outcompete, too.

Whether you like it or not, Silicon Valley startups do have a habit of overemphasizing the tech aspects of their companies to get the best talent. It isn't a bad strategy, considering that it makes sure that your business or service isn't susceptible to a technologically superior startup showing up and providing the same services. It is indeed true that there isn't anything groundbreaking about Airbnb or Zenefits (at least technologically). Uber has disrupted the way we travel using technology. Though it isn't as complex as Google, it is still a valid disruption using tech.

Well, it isn't always true that unicorns are easy to outcompete. I could argue that Amazon (not AWS) isn't anything special either. The point of a unicorn isn't to develop complex tech. At scale, these companies are hard to beat.

"You are talking about either business complexity or the critical minimum amount of money that is necessary to enter and dominate a market. I am taking about the engineering complexity."

Nope, I'm talking about engineering complexity.

"I could create Facebook in a weekend!" became such a recurring post on HN that posts about how you really couldn't became cliche, too. Seriously, yes, these "unicorns" really are doing really hard work. In another 30 years maybe you'll be able to turn a crank and produce a unicorn-scale codebase, but we definitely are not there today. Even in the last 5 years a lot of tools have come out to make it noticeably easier.

(Note how I said "hard" work. Whether or not it's valuable is an entirely different discussion. Hate the unicorns all you want, it doesn't make them any easier to engineer. I suspect you may be falling for the "I don't like X so X must have every negative quality" cognitive trap.)

Facebook is hard work? Scaling it might be somewhat difficult. But it's nothing particularly special. Facebook's success has almost nothing to do with technical achievements. It started as a simple PHP app, after all. One I could write (heck, I've made two different PHP social networks).

Looks like it's gonna be time for another round of "no, you can't write Facebook/Twitter in a week" again.

Yes, both are quite easy, as long as you ignore all the parts that make it hard. Like scaling. Lots of things are easy if they don't have to scale.

> Looks like it's gonna be time for another round of "no, you can't write Facebook/Twitter in a week" again.

Certainly not today's Facebook or Twitter, no. But the initial versions were very simple things. Anyone can make a Facebook or Twitter. Not anyone can grow it to a userbase of hundreds of millions of users. That was what was special, not something technical. Scaling wasn't an issue; once you have investment and users, you just throw money at the problem.

> Not anyone can grow it to a userbase of hundreds of millions of users.

Yep.

> Scaling wasn't an issue; once you have investment and users, you just throw money at the problem.

Yeah not really. The CAP theorem is going to bite you if you just buy more servers. Twitter suffered huge growing pains as it tried to scale after becoming mainstream--remember the "fail whale?" Facebook completely re-engineered PHP to address performance and scale issues.

Hmm, maybe using 'throwing money at the problem' was a poor choice, it's not quite what I meant. But yeah, Facebook had enough money they could hire people to work full-time on writing a PHP-to-C++ compiler. It's the sort of hack that typifies Facebook.

The hard part of a service like Facebook or Twitter is actually getting the users. Scaling is a problem that has been solved ages ago. It is something that will come naturally as you throw money/people on a service that is growing organically.

You don't work in "cloud", do you?

Scaling is solvable, but it is not solved. If you have to throw money/people at the problem, well, that means it is a problem, right?

Getting from any place in a western country to a different place in a western country (possibly a different one) is solved. It costs money and time, an estimate for both is often available using ITA Matrix or Kayak or Orbitz or Expedia. There's effort involved, yes, but it is not generally considered a problem in the circles I frequent.

>> Scaling it might be somewhat difficult.

Facebook has what, almost a billion and a half users? 500PB of data?

They are likely the largest systems of their kind in a few areas. It has to be more than somewhat difficult.

They do today. They didn't start there. It's very difficult to build a system that handles Facebook's current load from day one. But scaling up a small system over many years to handle it, given bucketloads of cash? That's not so hard.

Reply on news.ycombinator.com