4 ms·
I don't understand why so many large companies use platform abstractions. At a certain size you're big enough to have an iOS team that develops natively in Swi
by wvenable 7y ago
I don't understand why so many large companies use platform abstractions. At a certain size you're big enough to have an iOS team that develops natively in Swift/ObjC and an Android team developing natively in Kotlin or Java. Developing directly for the platform, with expertise in that platform, is a proven long term bet. Screwing around with platform abstractions seems much riskier.
The situation is a lot different if you're a small organization (or individual) and just don't have the resources for platform specific experts.
- Androider 7y agoHeadcount 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 agoBut 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 agoBut 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 agoYes, 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 agoI 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?
- kerbs 7y agoDo 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.
- ysavir 7y ago> I don't understand why so many large companies use platform abstractions. At a certain size you're big enough to have an iOS team that develops natively in Swift/ObjC and an Android team developing natively in Kotlin or Java. Because whoever made the decision to move to an abstraction gets to highlight "eliminated redundancies and saved the company $XMM/year" in their next performance review/resume.
- throw_m239339 7y ago> I don't understand why so many large companies use platform abstractions Even large companies can be cheap. Hiring developers is a complicated and costly process. But I'd wager that using a solution that the company or a middle manager X,Y,Z didn't vet before can also be a complicated a costly process. Plenty of language X shops refuse to use language Y for political reasons.
- obstacle1 7y ago> I don't understand why so many large companies use platform abstractions. At a certain point you'd rather have your developers focusing on tackling domain complexity, not stack complexity. If I can normalize my developers' skillsets I can shuffle them around at will to address whatever problems the business/product needs to be addressing -- quickly. Can't do that as easily if you need to do a bunch of platform-specific stuff as well.