9 ms·

Tangential to this, he says Airbnb has 100 mobile devs writing about 80k LoC of app code, 40K LoC of infra, and 220 "screens". We've got an app with about the s

by crabl 8y ago

Tangential to this, he says Airbnb has 100 mobile devs writing about 80k LoC of app code, 40K LoC of infra, and 220 "screens". We've got an app with about the same "dimensions", developed in a similar timeframe, with some very complex financial business logic and 2 developers working on it... what on Earth do their devs spend their time on? Is their engineering organization really _that_ inefficient?

apahwa 8y ago
"For reference, we have about 10x the amount of code and 4x the number of screens on each native platform". So the amount of code and the complexity is substantially more difficult than you describe. You probably also don't have as rigorous AB testing, logging, internationalization, contributions to open source, etc.
- deleted 8y ago
  [deleted]
- Tade0 8y ago
  I used to be a CKEditor core dev. The codebase was 150k LOC of (mighty complex at times)JS and there were four of us working on the LTS(4.x) - we were somewhat understaffed, but not "we need a hundred devs for this" understaffed. On the other hand last year I spent two weeks working on a project for which I was borrowed from another one - they had a total of 120k LOC(Java, TypeScript), twenty people and at least the front-end was a dumpster fire. I guess people don't scale well.
  - hokkos 8y ago
    I guess quality is a factor, because CKEditor 4.X might have a lot of lines but it is one of the worst library I had the displeasure to use.
    - bigmanwalter 8y ago
      I use it extensively in my current project and it is a joy. Different strokes for different folks.
pgsandstrom 8y ago
In my experience, in such a large and "app-centric" company the requirements on the app is changing constantly. Just having a specification that you implement is a hundred times easier than building a constantly evolving target.
- hardwaresofton 8y ago
  Also, once you have a lot of developers, the urge to over-engineer grows exponentially
  - mychael 8y ago
    Truer words have never been spoken on Hacker News.
  - osrec 8y ago
    This is often driven by the developers who don't want to appear to be redundant (and who can blame them - everyone wants to hold on to their job!)
- blub 8y ago
  So in other words, you think they don't have a spec and they're throwing more bodies at the problem instead of fixing their process? That would be very short-sighted, but it could be possible.
  - htormey 8y ago
    Large consumer apps generally are iterative affairs where the engineers & designers have a big say in the final product. At any given time Airbnb probably has multiple cross functional teams building different features. These teams are probably constantly testing and iterating the final design based on user research and testing. At least that was my experience working at Facebook on their iOS app.
deleted 8y ago
[deleted]
deleted 8y ago
[deleted]
101km 8y ago
My pet theory is that valuation is in part derived from engineer head count. Please note that this isn't a "I could build twitter in a weekend, why do they even have so many people" comment. I am not privy to the scope of work inside of AirBnB and can't really comment whether a large amount of inefficiency exists - but if it does, perhaps this is a plausible explanation as to how that can be. For an earlier stage company some mental gymnastics can justify the statement that in the event the startup doesn't become a unicorn 100 engineers are still "worth $100m" to big corporate buyers as a sort of big acquihire. This provides a hedge against failure. It also provides arguably necessary redundancy during a volatile growth stage. A higher bus factor if you will. https://en.wikipedia.org/wiki/Bus_factor https://en.wikipedia.org/wiki/Bus_factor And so a slightly inflated head count early on based on the above principals ensures that bureaucracy, having reached critical mass, keeps on expanding. At the present point, there's no plausible scenario for 100 to be reduced to 25 when the company is growing and doing well. If AirBnB suffers a calamity and its network effects somehow start disintegrating, holding on to these people could ultimately increase the sale price - the brand would have suffered, the apartment inventory is reduced, but you're still left with IP and engineers to hawk. In the event there are no buyers you could significantly stretch out the runway by multiple rounds of layoffs from this group, claim a successful turn around with the fat trimmed, and raise a new round of financing.
dmode 8y ago
Tbf, there are several very complex host side features and customer support features that are not really readily visible to an Airbnb booker. I was trying to list my space and came across the workflow.
blub 8y ago
This topic comes up every now and then regarding different start ups. A part of that is required because they're working on some difficult projects, internationalisation is hard, etc, etc. However, a simple 80kloc system (simple as in no critical safety requirements, very complex algorithms or heavy regulation) is perfectly manageable for a four person team. A lot of that head count is likely required because they need a large number of employees to attract investment, because scaling start ups are bad at processes (resulting in inefficiencies) and possibly because early employees want to move up the ladder, so they need someone to manage.
danpalmer 8y ago
That's just the React Native. It sounds like in total they have nearly 1m lines and 800 "screens". Between 100 devs that sounds about right. For comparison, Uber have 400 devs working on 3m lines across iOS and Android.
- dxhdr 8y ago
  3 million lines of front-end mobile code? That is impressive. How many screens does the Uber app have?
Tostino 8y ago
For real... i've had a ~4-5 dev team for the past three years, and our main application code is ~200k lines of java, ~70k lines of stored procedures, and a ton of other ancillary reporting code / etl code which i'm not counting. I just don't understand where they must be spending their time for an application of that size / complexity.
- gpeal 8y ago
  You are comparing the wrong numbers. We had 120,000 lines of RN code but RN only accounted for 10-20% of our mobile engineering.
batmansmk 8y ago
The numbers are super off yes. - 1 dev, 9 months project, 16k LoC excluding comments, including UT. - 16 devs, 2 years project, 200k LoC excluding comments, including UT.
gpeal 8y ago
You are comparing the wrong numbers. We had 120,000 lines of RN code but RN only accounted for 10-20% of our mobile engineering.
cwalcott 8y ago
I think this thread gives some good answers to this: https://twitter.com/jandersen/status/1009247005233692672 https://twitter.com/jandersen/status/1009247005233692672. Basically, problems you get from being at massive scale and supporting a large number of devices.
pier25 8y ago
That's on average 2 screen per dev.

by crabl 8y ago

apahwa 8y ago

"For reference, we have about 10x the amount of code and 4x the number of screens on each native platform". So the amount of code and the complexity is substantially more difficult than you describe. You probably also don't have as rigorous AB testing, logging, internationalization, contributions to open source, etc.

deleted 8y ago
[deleted]
Tade0 8y ago
I used to be a CKEditor core dev. The codebase was 150k LOC of (mighty complex at times)JS and there were four of us working on the LTS(4.x) - we were somewhat understaffed, but not "we need a hundred devs for this" understaffed. On the other hand last year I spent two weeks working on a project for which I was borrowed from another one - they had a total of 120k LOC(Java, TypeScript), twenty people and at least the front-end was a dumpster fire. I guess people don't scale well.
- hokkos 8y ago
  I guess quality is a factor, because CKEditor 4.X might have a lot of lines but it is one of the worst library I had the displeasure to use.
  - bigmanwalter 8y ago
    I use it extensively in my current project and it is a joy. Different strokes for different folks.

pgsandstrom 8y ago

In my experience, in such a large and "app-centric" company the requirements on the app is changing constantly. Just having a specification that you implement is a hundred times easier than building a constantly evolving target.

hardwaresofton 8y ago
Also, once you have a lot of developers, the urge to over-engineer grows exponentially
- mychael 8y ago
  Truer words have never been spoken on Hacker News.
- osrec 8y ago
  This is often driven by the developers who don't want to appear to be redundant (and who can blame them - everyone wants to hold on to their job!)
blub 8y ago
So in other words, you think they don't have a spec and they're throwing more bodies at the problem instead of fixing their process? That would be very short-sighted, but it could be possible.
- htormey 8y ago
  Large consumer apps generally are iterative affairs where the engineers & designers have a big say in the final product. At any given time Airbnb probably has multiple cross functional teams building different features. These teams are probably constantly testing and iterating the final design based on user research and testing. At least that was my experience working at Facebook on their iOS app.

deleted 8y ago

[deleted]

deleted 8y ago

[deleted]

101km 8y ago

My pet theory is that valuation is in part derived from engineer head count. Please note that this isn't a "I could build twitter in a weekend, why do they even have so many people" comment. I am not privy to the scope of work inside of AirBnB and can't really comment whether a large amount of inefficiency exists - but if it does, perhaps this is a plausible explanation as to how that can be. For an earlier stage company some mental gymnastics can justify the statement that in the event the startup doesn't become a unicorn 100 engineers are still "worth $100m" to big corporate buyers as a sort of big acquihire. This provides a hedge against failure. It also provides arguably necessary redundancy during a volatile growth stage. A higher bus factor if you will. https://en.wikipedia.org/wiki/Bus_factor https://en.wikipedia.org/wiki/Bus_factor And so a slightly inflated head count early on based on the above principals ensures that bureaucracy, having reached critical mass, keeps on expanding. At the present point, there's no plausible scenario for 100 to be reduced to 25 when the company is growing and doing well. If AirBnB suffers a calamity and its network effects somehow start disintegrating, holding on to these people could ultimately increase the sale price - the brand would have suffered, the apartment inventory is reduced, but you're still left with IP and engineers to hawk. In the event there are no buyers you could significantly stretch out the runway by multiple rounds of layoffs from this group, claim a successful turn around with the fat trimmed, and raise a new round of financing.

dmode 8y ago

Tbf, there are several very complex host side features and customer support features that are not really readily visible to an Airbnb booker. I was trying to list my space and came across the workflow.

blub 8y ago

This topic comes up every now and then regarding different start ups. A part of that is required because they're working on some difficult projects, internationalisation is hard, etc, etc. However, a simple 80kloc system (simple as in no critical safety requirements, very complex algorithms or heavy regulation) is perfectly manageable for a four person team. A lot of that head count is likely required because they need a large number of employees to attract investment, because scaling start ups are bad at processes (resulting in inefficiencies) and possibly because early employees want to move up the ladder, so they need someone to manage.

danpalmer 8y ago

That's just the React Native. It sounds like in total they have nearly 1m lines and 800 "screens". Between 100 devs that sounds about right. For comparison, Uber have 400 devs working on 3m lines across iOS and Android.

dxhdr 8y ago
3 million lines of front-end mobile code? That is impressive. How many screens does the Uber app have?

Tostino 8y ago

For real... i've had a ~4-5 dev team for the past three years, and our main application code is ~200k lines of java, ~70k lines of stored procedures, and a ton of other ancillary reporting code / etl code which i'm not counting. I just don't understand where they must be spending their time for an application of that size / complexity.

gpeal 8y ago
You are comparing the wrong numbers. We had 120,000 lines of RN code but RN only accounted for 10-20% of our mobile engineering.

batmansmk 8y ago

The numbers are super off yes. - 1 dev, 9 months project, 16k LoC excluding comments, including UT. - 16 devs, 2 years project, 200k LoC excluding comments, including UT.

gpeal 8y ago

You are comparing the wrong numbers. We had 120,000 lines of RN code but RN only accounted for 10-20% of our mobile engineering.

cwalcott 8y ago

I think this thread gives some good answers to this: https://twitter.com/jandersen/status/1009247005233692672 https://twitter.com/jandersen/status/1009247005233692672. Basically, problems you get from being at massive scale and supporting a large number of devices.

pier25 8y ago

That's on average 2 screen per dev.