Because adding more engineers will make the development slower ( https://en.wikipedia.org/wiki/The_Mythical_Man-Month ).
Why WhatsApp Only Needs 50 Engineers for Its 900M Users
11–20 of 255 posts
Re: Why WhatsApp Only Needs 50 Engineers for Its 900M Users
#12I 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.
Re: Why WhatsApp Only Needs 50 Engineers for Its 900M Users
#13Re: Why WhatsApp Only Needs 50 Engineers for Its 900M Users
#14I 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
#15Re: Why WhatsApp Only Needs 50 Engineers for Its 900M Users
#16I 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…
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
#17Answer: 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
#18This 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
#19I 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.
Re: Why WhatsApp Only Needs 50 Engineers for Its 900M Users
#20My 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.