4 ms·

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 de

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.
- wvenable 7y ago
  > Because they have massive platform specific teams, and they would like not to. I'm somewhat shocked at the size of some of the mobile app development teams at some of these companies. There's no way they need that many developers. What are 100's of developers doing on a single app for a single platform? How is there enough work for that many people? The overhead must be unbelievable. I can't imagine that adding a platform abstraction is going to fundamentally change the headcount if your headcount is already ridiculous. It just doesn't remove that much effort.
  - Androider 7y ago
    The Facebook app is like Microsoft Word. Everyone only uses 20%, but it's a different 20% for each. The app is a hojillion megabytes, and serves literally billions of users. There's features in there that addresses some specific niche in Africa for "only" 50 million users, that some sub-team of a sub-team is tasked with maintaining.
    - wvenable 7y ago
      Microsoft doesn't use an abstraction to create Word for Mac OS. They have shared code, yes. But they are different products with different user interfaces to match their respective platforms. I'm not sure why mobile is so different that one needs a platform abstraction if you've already got a bazillion developers working on the product. Of course, Facebook does benefit by owning that abstraction making it exactly what they need. For everyone else, the risk is a bit different.
      - Androider 7y ago
        Microsoft has been building Word on Windows since the 80's, so it's never going to be re-written. I'm not that familiar with the Mac version of Word, but I find the Mac Excel version lacking compared to its Windows counterpart. For Word and Excel for iOS and Android they use... React Native [1]. [1] https://blog.appfigures.com/microsoft-goes-all-in-on-react-native-for-their-mobile-apps/ https://blog.appfigures.com/microsoft-goes-all-in-on-react-n...
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.

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.
wvenable 7y ago
> Because they have massive platform specific teams, and they would like not to. I'm somewhat shocked at the size of some of the mobile app development teams at some of these companies. There's no way they need that many developers. What are 100's of developers doing on a single app for a single platform? How is there enough work for that many people? The overhead must be unbelievable. I can't imagine that adding a platform abstraction is going to fundamentally change the headcount if your headcount is already ridiculous. It just doesn't remove that much effort.
- Androider 7y ago
  The Facebook app is like Microsoft Word. Everyone only uses 20%, but it's a different 20% for each. The app is a hojillion megabytes, and serves literally billions of users. There's features in there that addresses some specific niche in Africa for "only" 50 million users, that some sub-team of a sub-team is tasked with maintaining.
  - wvenable 7y ago
    Microsoft doesn't use an abstraction to create Word for Mac OS. They have shared code, yes. But they are different products with different user interfaces to match their respective platforms. I'm not sure why mobile is so different that one needs a platform abstraction if you've already got a bazillion developers working on the product. Of course, Facebook does benefit by owning that abstraction making it exactly what they need. For everyone else, the risk is a bit different.
    - Androider 7y ago
      Microsoft has been building Word on Windows since the 80's, so it's never going to be re-written. I'm not that familiar with the Mac version of Word, but I find the Mac Excel version lacking compared to its Windows counterpart. For Word and Excel for iOS and Android they use... React Native [1]. [1] https://blog.appfigures.com/microsoft-goes-all-in-on-react-native-for-their-mobile-apps/ https://blog.appfigures.com/microsoft-goes-all-in-on-react-n...

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.