5 ms·

Headcount is the biggest expense in almost all companies. Larger companies also have larger and more complex apps, so while a small company may have a small iOS

Headcount is the biggest expense in almost all companies. Larger companies also have larger and more complex apps, so while a small company may have a small iOS development team, large companies have massive iOS development teams. Massive team * number of platforms = serious money. You also get into all kinds of platform and feature parity issues. "Why can't we do X on Android but only on iOS?", "Well because they're two different teams, with different PMs, developers and release schedules. And please don't ask about the web team, who are in <different city>". Using abstractions you can have one massive "core" team, and several smaller platform expert teams. On the face of it, it makes sense.

wvenable 7y ago
But developer headcount doesn't scale to the size of the installed base. Whether you have hundred-thousand users or a million users, you don't need a larger development team. Once you have a reasonable-sized team that can make the app, you don't need any more developers, no matter how successful your app is. Having different teams for different platforms might result in a slightly larger headcount my point is that risk isn't worth that meager benefit if you can afford it. You're still going to need platform-specific knowledge, and then the abstraction knowledge, and you're still deploying to multiple platforms! You also don't need to let the technology choices drive the team structure. You can share a huge number of resources between iOS and Android including planning, management, assets, etc. Sure you're building two different apps but you don't need to keep those teams in different cities.
- Androider 7y ago
  But the question was why large companies use platform abstractions. Because they are large in headcount, by definition. Because the apps are already large. Because they have massive platform specific teams, and they would like not to. Because the teams are geographically spread out, for a myriad of reasons. The large companies are what they are, and you cannot apply the same type of thinking to their problems as if you were designing the organization from scratch. There's problems they have, and the team structure they would like to have, and based on that the technology choice to favor abstraction makes sense.
  - wvenable 7y ago
    Yes, many large companies seek technological solutions to political problems. I've worked for dysfunctional organizations; they want technology to provide the decisions bottom-up because, for whatever reason, nobody wants to make any hard calls. These projects fail because you simply can't have success that way. If this is a political and organizational problem, then this choice of technology is entirely not about the pros and cons that have probably been debated to death in this topic. I agree. I think you've added some really good insight in this conversation. But I think that solution is dumb. It's especially dumb for a software company because software is their core competency. That's where they should be spending their resources on. They should be minimizing costs but not at the cost of their core product.
    - Androider 7y ago
      I wouldn't class this as political problems. Is Facebook having a gazillion developers on their app a political problem, or necessary given what they want it to do? How is replicating that for each platform a good solution, in any sense (political or technical)? Tech companies core competencies are the service or product that they provide. Making it N times for N platforms is a hurdle that doesn't improve on the core, it's a cost of the fragmented market. I'm arguing that it makes perfect sense both technically and politically to focus your vast majority of developers on your core, and only having specialized platform teams were necessary as a cost of doing business. How is developers re-implementing every UI screen and feature across iOS and Android helping Shopify customers sell more merch?
      - wvenable 7y ago
        > Is Facebook having a gazillion developers on their app a political problem, or necessary given what they want it to do? Yes. How is it not a political problem? It's not a technological one. > How is replicating that for each platform a good solution, in any sense (political or technical)? It doesn't change anything politically but technologically platform abstractions are never 100%. You always need an expert for each platform anyway and by targeting the abstraction rather than the platform you're just targeting a crappier experience for your end users and often your developers as well. React Native is not without it's issues. So what's the benefit? You're not saving expertise. Even sharing code isn't that important -- once decisions have been made, features planned out in detail, server APIs created, the actual platform specific code is a pretty small part overall. You still have to test on each platform individually. Fix platform specific bugs even in non-platform specific code. And you're not creating a dependency on a 3rd party that you don't control. > How is developers re-implementing every UI screen and feature across iOS and Android helping Shopify customers sell more merch? How is it not? I mean the argument here is that there is a huge savings to justify the risk but I don't think that's true.
- horsawlarway 7y ago
  As someone leading a team that does releases to clients, this is a pretty naive take. As you scale you get quite a few constraints that require additional manpower 1. Scaling generally means revenue, which means more internal teams pumping out more business products/features. Those features often need some sort of mobile integration. So you not only have your planned features, you have the features other teams would like you to work on. The larger the company, the more requests like this you get. Feature velocity MATTERS. 2. As you scale you almost always have to rework your backend to some extent to keep up with load/feature growth. This means existing features are at risk of using deprecated & older APIs/Tools and need attention in order to keep working and allow scaling. 3. By the time you're scaling into the millions, you're almost certainly acquiring enterprise users. You can skate by in the individual/small/medium business with some pretty glaring bugs (things like 2% of all android users see crashes at startup). This wiggle rooms goes away when you start working with enterprise customers (or at least gets considerably tighter). It's an inconvenience when your 15 person org has that one phone that doesn't work right. It's a showstopper when the 10,000 seat org has 600+ users who can't use the product. Those are just a few of the differences that happen at scale. ---- Long story short, you're not really wrong from a technical side - A small dev team can absolutely make a small & focused app and manage to scale. You're just glossing over the politics of working in an org that's successfully scaling. It turns out being able to get additional employees that don't need extensive mobile experience and can just crank out features is a huge pressure release. It lets that original tiny dev team (the folks who could write a fine native app without any issue) focus on bigger/harder problems.
  - wvenable 7y ago
    You have what I'm saying backwards. I'm not talking about a small dev team. My whole point is that when you have a large dev team, that you don't need that platform abstraction because you have the manpower to handle multiple platforms natively. Especially if you are a software company and not just a widget company that also has an app. > It turns out being able to get additional employees that don't need extensive mobile experience and can just crank out features is a huge pressure release. The idea that because you're using React Native you can throw developers with no mobile experience at problems seems naive to me. I also don't believe feature velocity scales with the number of developers. This is the whole 9 women making a baby in a month thing. This especially true on a mobile app which is constrained by the interface and user expectations. You're not going to have hundreds of developers working on a far flung features away from everything else because the apps are small and tight even if complex. There are exceptions but most mobile apps are focused on a small critical path. It seems to me that all these companies with hundreds of mobile developers aren't producing better results than those with dozens. In fact, it usually seems the opposite. There are exceptions but when was the last time a giant company made such extensive changes to their app that justified that number of developers? A justified use of developers is native versions for each platform.
kerbs 7y ago
Do you think AirBnB's headcount was smaller when they were all-in on React Native? Do you think they had to go on a hiring spree because they went back to native? I'm skeptical there is a correlation.

wvenable 7y ago

But developer headcount doesn't scale to the size of the installed base. Whether you have hundred-thousand users or a million users, you don't need a larger development team. Once you have a reasonable-sized team that can make the app, you don't need any more developers, no matter how successful your app is. Having different teams for different platforms might result in a slightly larger headcount my point is that risk isn't worth that meager benefit if you can afford it. You're still going to need platform-specific knowledge, and then the abstraction knowledge, and you're still deploying to multiple platforms! You also don't need to let the technology choices drive the team structure. You can share a huge number of resources between iOS and Android including planning, management, assets, etc. Sure you're building two different apps but you don't need to keep those teams in different cities.

Androider 7y ago
But the question was why large companies use platform abstractions. Because they are large in headcount, by definition. Because the apps are already large. Because they have massive platform specific teams, and they would like not to. Because the teams are geographically spread out, for a myriad of reasons. The large companies are what they are, and you cannot apply the same type of thinking to their problems as if you were designing the organization from scratch. There's problems they have, and the team structure they would like to have, and based on that the technology choice to favor abstraction makes sense.
- wvenable 7y ago
  Yes, many large companies seek technological solutions to political problems. I've worked for dysfunctional organizations; they want technology to provide the decisions bottom-up because, for whatever reason, nobody wants to make any hard calls. These projects fail because you simply can't have success that way. If this is a political and organizational problem, then this choice of technology is entirely not about the pros and cons that have probably been debated to death in this topic. I agree. I think you've added some really good insight in this conversation. But I think that solution is dumb. It's especially dumb for a software company because software is their core competency. That's where they should be spending their resources on. They should be minimizing costs but not at the cost of their core product.
  - Androider 7y ago
    I wouldn't class this as political problems. Is Facebook having a gazillion developers on their app a political problem, or necessary given what they want it to do? How is replicating that for each platform a good solution, in any sense (political or technical)? Tech companies core competencies are the service or product that they provide. Making it N times for N platforms is a hurdle that doesn't improve on the core, it's a cost of the fragmented market. I'm arguing that it makes perfect sense both technically and politically to focus your vast majority of developers on your core, and only having specialized platform teams were necessary as a cost of doing business. How is developers re-implementing every UI screen and feature across iOS and Android helping Shopify customers sell more merch?
    - wvenable 7y ago
      > Is Facebook having a gazillion developers on their app a political problem, or necessary given what they want it to do? Yes. How is it not a political problem? It's not a technological one. > How is replicating that for each platform a good solution, in any sense (political or technical)? It doesn't change anything politically but technologically platform abstractions are never 100%. You always need an expert for each platform anyway and by targeting the abstraction rather than the platform you're just targeting a crappier experience for your end users and often your developers as well. React Native is not without it's issues. So what's the benefit? You're not saving expertise. Even sharing code isn't that important -- once decisions have been made, features planned out in detail, server APIs created, the actual platform specific code is a pretty small part overall. You still have to test on each platform individually. Fix platform specific bugs even in non-platform specific code. And you're not creating a dependency on a 3rd party that you don't control. > How is developers re-implementing every UI screen and feature across iOS and Android helping Shopify customers sell more merch? How is it not? I mean the argument here is that there is a huge savings to justify the risk but I don't think that's true.
horsawlarway 7y ago
As someone leading a team that does releases to clients, this is a pretty naive take. As you scale you get quite a few constraints that require additional manpower 1. Scaling generally means revenue, which means more internal teams pumping out more business products/features. Those features often need some sort of mobile integration. So you not only have your planned features, you have the features other teams would like you to work on. The larger the company, the more requests like this you get. Feature velocity MATTERS. 2. As you scale you almost always have to rework your backend to some extent to keep up with load/feature growth. This means existing features are at risk of using deprecated & older APIs/Tools and need attention in order to keep working and allow scaling. 3. By the time you're scaling into the millions, you're almost certainly acquiring enterprise users. You can skate by in the individual/small/medium business with some pretty glaring bugs (things like 2% of all android users see crashes at startup). This wiggle rooms goes away when you start working with enterprise customers (or at least gets considerably tighter). It's an inconvenience when your 15 person org has that one phone that doesn't work right. It's a showstopper when the 10,000 seat org has 600+ users who can't use the product. Those are just a few of the differences that happen at scale. ---- Long story short, you're not really wrong from a technical side - A small dev team can absolutely make a small & focused app and manage to scale. You're just glossing over the politics of working in an org that's successfully scaling. It turns out being able to get additional employees that don't need extensive mobile experience and can just crank out features is a huge pressure release. It lets that original tiny dev team (the folks who could write a fine native app without any issue) focus on bigger/harder problems.
- wvenable 7y ago
  You have what I'm saying backwards. I'm not talking about a small dev team. My whole point is that when you have a large dev team, that you don't need that platform abstraction because you have the manpower to handle multiple platforms natively. Especially if you are a software company and not just a widget company that also has an app. > It turns out being able to get additional employees that don't need extensive mobile experience and can just crank out features is a huge pressure release. The idea that because you're using React Native you can throw developers with no mobile experience at problems seems naive to me. I also don't believe feature velocity scales with the number of developers. This is the whole 9 women making a baby in a month thing. This especially true on a mobile app which is constrained by the interface and user expectations. You're not going to have hundreds of developers working on a far flung features away from everything else because the apps are small and tight even if complex. There are exceptions but most mobile apps are focused on a small critical path. It seems to me that all these companies with hundreds of mobile developers aren't producing better results than those with dozens. In fact, it usually seems the opposite. There are exceptions but when was the last time a giant company made such extensive changes to their app that justified that number of developers? A justified use of developers is native versions for each platform.

kerbs 7y ago

Do you think AirBnB's headcount was smaller when they were all-in on React Native? Do you think they had to go on a hiring spree because they went back to native? I'm skeptical there is a correlation.