Live data from Hacker News

Why WhatsApp Only Needs 50 Engineers for Its 900M Users

wired.com

11–20 of 255 posts

Re: Why WhatsApp Only Needs 50 Engineers for Its 900M Users

#12
post #5

I got my first ever spam on whatsapp the other day from someone who had never been a contact, and there seems to be no way whatsoever to prevent it. So maybe they should hire 1 more engineer to work on spam.

I installed whatsapp and the first three messages I received were spam, all within about 30 minutes. I uninstalled whatsapp.

Re: Why WhatsApp Only Needs 50 Engineers for Its 900M Users

#13
This articles doesn't look that convincing to me. I has no technical details to prove that Erlang was the major reason why WhatsApp was scalable. I think the low number of engineers has more to do with the simplicity of their product than with this particular language choice.

Re: Why WhatsApp Only Needs 50 Engineers for Its 900M Users

#14
WhatsApp seems to be a great example of designing your system with the best tools available. To go from nothing to pretty much being the de-facto modern replacement for SMS in a couple of years is an amazing achievement.

I really need to sit down and spend some time properly learning a functional language. I can hack my way through Haskell code but I do it in a very non-Haskell way. I really need to change that. My primary language is C++ and I am open to any recommendations for what direction to go in :)

Re: Why WhatsApp Only Needs 50 Engineers for Its 900M Users

#16

I don't quite understand the correlation. If the article was about how Whatsapp achieves scale and parallelism through functional languages, then fair enough. But I'm not sure it's fair to say they need 50 engineers, in part, because of the language choice ? Surely they need 50 engineers because their product is fairly simple and there's no need to have more engineers than features. Maybe the point it should have mad…

Well, isn't the language a hood enough reason?

I think most seasoned game developers would be faster making a simple 3D game with Unity rather than just openGL + C ( mainly because with Unity you get soon much boilerplate-y stuff out of the box)

The language and the amazing properties of failure tolerance could be productivity multipliers ( think of the times you've had to deal with catastrophic failures of software)

Re: Why WhatsApp Only Needs 50 Engineers for Its 900M Users

#17
> Why WhatsApp Only Needs 50 Engineers for Its 900M Users

Answer: because sending short messages from A to B is basically a solved problem. There is even a programming language (Erlang) that was made with this application in mind. The prototypical "Hello World" example for Erlang is a messaging application.

Re: Why WhatsApp Only Needs 50 Engineers for Its 900M Users

#18
post #13

This articles doesn't look that convincing to me. I has no technical details to prove that Erlang was the major reason why WhatsApp was scalable. I think the low number of engineers has more to do with the simplicity of their product than with this particular language choice.

WhatsApp engineers themselves said Erlang was the main reason they were able to scale as well as they did.

Re: Why WhatsApp Only Needs 50 Engineers for Its 900M Users

#19
I have to say I was expecting this to be a little older - it's really impressive that Facebook have kept the culture and tiny headcount of that team.

I doubt it's ever a good idea for a company like Facebook to do layoffs but I wonder if there are any lessons from the WhatsApp team for a company that size - their intern cohort looked way bigger than 50 and they seem to have almost 50 offices [0]. Obviously a very different product and much more complex but it's interesting to wonder what the same product led by Jan Koum would hypothetically look like.

[0] http://newsroom.fb.com/company-info/

Re: Why WhatsApp Only Needs 50 Engineers for Its 900M Users

#20
(Disclaimer: I teach this stuff) Good article. It's a keeper. Touches on a lot of things I've been telling clients for years.

My takeaways:

- Pure functions in little composable pieces. Screw the fact you can't find programmers. With 1/20th the staff, it's not important

- Zero to few meetings. Keep focused on one thing. No playing around with WhizzBang Platform 7.0 because all the cool kids are using it. Mind your knitting.

- Keep It Simple, Stupid. Engineers are our own worst enemy. Solve the most simple problem possible. Then add complexity a little bit at a time, only as a last resort. For those of you saying "But messaging is solved", "Erlang was written for messaging", and so forth, this is where you missed. Any complex system (with a few notable exceptions) will look very simple when solved in this manner. In fact, that's the entire point.

- Running and deploying are the same thing. CI/CD. There is no Big Red Button to push because we're always working on the airplane engines while the plane is flying

Coming from a traditional OOA/D/P background, this mentality was extremely foreign to me. Even though I was using and talking about TDD, it was still in terms of composing and re-arranging object graphs. It wasn't until I got into F# several years ago that the pieces started coming together. This is a very difficult conceptual leap to make, because a lot of the ways you work looks completely ass-backwards to folks who are used to doing it the other way.

Post reply on HN