What exactly do all of these engineers do at single-focus companies like Snap? I guess I don't understand where you could find enough work for hundreds of engineers on a product like that?
1. Many engineers do not work on core products. Many of these companies operate like quasi accelerators at times: hire smart engineers since you can afford it, hire a few good PMs, see what happens, then market the most promising results. Twitter had Vine, Snap had Spectacles, and maybe one of the best examples of this is Amazon. They didn't need thousands of engineers to run an e-commerce site, but they did need them to build out a cloud, and Alexa, and a video streaming service, etc. Other companies want to replicate this model.
2. Scale is hard. As soon as you hit a limit of what off the shelf software or current open source offerings can do, you have a hard problem on your hands. There are certainly more 'web scale' products that exist now to make this process easier for startups, but it can still happen. It's also possible that even if there are products that can scale, it would end up being cheaper to spin up a large team of good engineers to replicate a commercial offering if you're optimistic about the companies growth.
There's tonnes of examples backing up your first point though, 100% accurate.
If I remember correctly Shopify is something like 400k lines of Ruby on Rails code and 400 developers (i.e. one developer per 1000 LOC). Whereas I guess a 5k LOC codebase could be handled by a single developer.
That's a couple of weeks work.
EDIT: I'm being flippant, but to me a 400k code base is something 2 devs can put out in a few years. I'm pretty certain the present main code base I'm working on must be close to 400k and it's only ever had 2 devs working on it at any one time.
And we're always adding massive chunks of new functionality, and are regularly integrating with new third parties. And we total overhauled it last year to support i18n and it's now being regularly used in 3 languages and we can add more in literally a couple of days.
Ok it only handles hundreds of thousands of users, but I expect it to be millions within a couple of years and we're not even trying to load balance or anything yet.
You need these things to run a global operation at scale.
If you're not interested in running a global operation at scale, then you can be happy running a little self-serve application - but to create the phenomenon that is SnapChat requires a lot of coordinated effort. To think otherwise is just simply naive.
Now I don't think we have enough information to judge if 1800 is the wrong number for SnapChat or not. They very well may be overstaffed.
> develops games
Not in a long time. They're practically in maintenance mode with their games, DOTA 2 being the exception. Most of the creative talent there (people who worked on Half-Life, Portal, etc) has retired.
Valve is actually a good example of a company that's now incapable of doing anything really ambitious that has real demand. You know, like Half Life 3...
Not to mention internal engineering too, from dev-ops and platform to potentially even custom HR tools.
Again, not saying they're not overstaffed. But a lot of people seem to forget about the internal teams supporting other engineers/employees.
The employee count was like 260.
I'm sure there are hedge funds out there with only 100 employees and $30 billion under management.
That has nothing to do with anything.
We were a software company, the only thing we shipped was software. We shipped a hell of a lot more code than Snapchat. We had many products, some fairly complex. We even developed a bunch of internal tools as well.
I obviously wouldn't be comparing the head count of a financial management company with a software company.
Then a bunch are working on 'location based promoted filters", these are basically just graphic designers, or maybe web designers, but they are getting lumped in.
So companies have to continue hiring until they find that magical person who manages to do the work of 10 people. Some companies get lucky and find 5 of these people right off the bat, others, not so much.
It could also be the engineering culture. All it takes is a couple of lazy developers and the laziness culture beings to propagate to the rest of the company. One or two people being wishy-washy about delivery dates and meeting times will send the message to the rest of the team that it's ok for you to also be wishy-washy with these things. Management doesn't always think there's a culture problem, so they just increase headcount thinking that productivity directly correlates to headcount.
It's not fair to fully blame engineering for this. If the company doesn't have a strong engineering voice, you will get handed ridiculous requirements and specifications and yes, you'll need 50 more developers so you can meet the needs of the picky lead designer who wants pixel perfect function on every device ever created for every language for any feature.
All that being said, when a company is doing well, the executives and shareholders shout "Hire baby, hire" and so the machine brings on capacity with no real goal, other than expansion for its own sake.
I think a better contrast is Twitter. Thousands of employees and it feels almost nothing in terms of new features to show for it, minus changing a star over to a heart... (which btw, reportedly took two years to implement once the idea came about...)
It's also really easy to knock out a MVP that replicates 80% of snapchat features, but the real problem is getting the scale right, as conventional social networks are worthless without a huge pool of eyeballs for precisely targeted ads.
While I'm at it, I'd like to plant the thought that Social might be a perfect place for disruption again, but now with a non-profit/public strategy. Maybe with a huge initial donation it's more than enough as incremental user costs are minimal if we don't spend money optimizing for engagement and ads and use some decentralized tech lime swarm/ipfs, but that's for another time.
Also the weird corner cases in different platforms and the huge technical debt in most startups seem to sap a lot of energy.
Those qualities are completely valid business justifications for the swell, but the swell was largely unnecessary. If the technology were written well and scaled appropriately they could have easily gotten by with several hundred developers.
The most immediate problem in that industry is legacy technology. The technology is universally Java and it is often poorly written. Java is bloated enough on its own, required boilerplate, but bad software forces a multiplicative effect. Maintenance takes far more effort than originally authoring software in the first place, so a legacy Java application that is still being enhanced with new features can be scary massive.
Worse still is that this was a web-based business and historically very few people have understood web technologies well. If you go back far enough you will find that JavaScript was too slow to do anything and nobody took HTML seriously, so absolutely everything ends up in Java. Java isn't a web technology and would induce rabid insecurity into crappy developers who spent way too much on their education to qualify their insecurities. You quickly end up with really crappy code and needing 5-10x people to maintain it.
Eventually JavaScript got fast, so the business had the bright idea to offload everything in JavaScript. In the past nobody (well very few) wrote JavaScript well, because web technologies were slow and nobody took them seriously. Now there are still very few people who understand web technologies well and everybody else lives behind multiple frameworks and abstraction layers.
The horrid bloat before you had with Java... well now you have that in JavaScript too but you are continuing to develop and maintain on both sides of the fence so you need thousands of engineers just to keep the lights on. Oh, but wait it gets worse.
By now you should be asking yourself how the hell there are so many bad developers in the world and why hasn't the big corporation solved the bad developer problem. It is in their financial interest to solve this problem.... right? No, this is a cultural problem in the corporate world and so long as profit outpaces spend there isn't any financial incentive to fix anything particularly when fixes carry risks.
That cultural problem is that training and mentoring are rare in the corporate world. Furthermore, most developers aren't properly motivated to want to improve substantially enough to solve for valid business concerns. You have to understand that programming is a skill and like any skill the only valid discriminator of competence is deliberate practice (developers with initiative to takes risks to do innovating things). Most developers DO NOT want to take risks. They want to be employed.
Many developers want to go to work to perform only assigned tasks in their comfort zone, like in a factory, and then immediately turn their brains off as they go home according to a set time-frame. Personally, I would rather earn more money and have the freedom to easily move between employers if the need arises, which is only a common reality if you are more competent (more skilled) than other developers.
Ok, so, many developers suck because they aren't motivated to do wonderful things, and therefore you need A LOT of developers to compensate for the bad code (and as they continue to write bad code). The next logical question is why aren't the big corporations doing a better job of motivating their people.
Counter-intuitively, this problem is not solved by increasing compensation. If you increase compensation under the agreement that teams of developers will solve drastically more ambitious problems in more original (innovative) ways you are introducing risk to the developers' career. What happens in the case where a developer accepts higher compensation and yet fails to perform to the higher expectations? Remember that most developers want to keep their jobs. Employment is almost universally preferred to increased compensation others everybody would be entrepreneurs and nobody would be employees.
People capable of appreciating and accepting risks are self-motivated. This means such people tend to identify risks with their own initiative and are self-motivated to solve for the risk without awareness of an immediate reward. This is where increased practice becomes important and the resulting benefits aren't immediately clear, such as increased job security or a future promotion. This is also a behavioral quality much of the corporate world isn't willing to produce, so they leave it to the marketplace. Increased risk acceptance isn't the sort of quality that drives favorable annual reviews in much of the corporate world, as annual reviews reward quantitative performance metrics.
Talented people (people with the proper combination of practice, personality, and accomplishment) are rare and they take time to produce. It is so much cheaper to hire 5 times the crappy developers at 15 times the price than to wait for the golden unicorn to appear when you have work that needs to be performed RIGHT NOW. At least that is the common perception. There is also the common perception that many hands make light work.
I am of the mind that technology failures don't exist. There are only natural disasters and really bad decisions. One person's bad decision is another person's comfort blanket.