2 ms·

You seem to be describing the thing that most companies still are doing (at least a little bit), where the same team does apps for each platform. And sure, that

by derefr 3y ago

You seem to be describing the thing that most companies still are doing (at least a little bit), where the same team does apps for each platform. And sure, that's dumb and hard — polyglot programmers are hard to hire, it's hard to context switch, etc. But what I'm describing is different: in the old "porting" approach, rather than having "a mobile team" that is expected to know both iOS and Android, you would instead have an iOS team full of people hired specifically for their iOS expertise, that just do your iOS app, and who are not expected to know anything about Android; and vice-versa for an Android team. Your iOS team would be as distinct from your Android team as current mobile teams are from web-app teams (in companies whose native apps aren't just wrapped web-apps.) I know this isn't too relevant for SMBs who can't afford to hire O(N) entire teams just to launch an app on O(N) platforms. But the "let's share one codebase to every platform" efforts are almost always driven by corporations so large and so profitable that they can definitely afford O(N) teams of per-platform deep experts. Why is "the Facebook mobile app" a single shared codebase for every mobile platform? Why is "the Google Maps mobile app"? Slack and/or Discord (who used to be SMBs, but at this point could totally afford this)? Etc. These are all apps that would highly benefit from tight integration with each targeted platform. It almost seems like the smaller companies are the ones who more often have the "taste" to do the right thing here; while bigcorps — that can actually afford to do the right thing — are constitutionally incompatible with this idea somehow.

dathinab 3y ago
In my experience it's mostly the not very small but also not very large companies _which have a small set of very excellent programmers_ which do so, with some tech lead spearheading it and having the skill (but not time) to pull it of just by themself. But in larger companies this kind of team structure is rare, fleeting and if it exists most times focused on other more core business areas. I mean in a start up you might find people with skills they could get highly payed for working for a fraction of their salary due to various freedoms and work atmosphere aspects, so you might have an excellent skilled person you can put (or which puts themself) on working on such UI tasks. But in a large company you have this rarely, most highly skilled people there are also highly payed and in turn to expensive to put on such tasks which on paper don't yield that high value (not on a "they can't afford it basisi" but on a "it makes financially no sense" basis). Similar even if that isn't a problem such people tend to be much more constrained by other influences. Then there is the problem that software development isn't that easy to scale (I think most more experienced people know the "onboard a person to gain speed but losing speed" kind of situation). So often approaches to development become more stream lined, with more overhead, and in turn more expensive (but scaling to more devs). At which points considerations for cutting costs come in and in turn the "only one app" decisions is on the table. A good technical example is if you compare (a bit older) react + full reflux with the dart blocks pattern at the core they are the same but the react one is scaling better with many devs while also but in turn also has more overhead by splitting more things apart spreading you logic across all kinds of (standardized) places. Through probably most important companies do not thing in terms of "can we afford it" but in terms of "does that yield enough profits for it to be worth it" (assuming they can afford it).

by derefr 3y ago

dathinab 3y ago

In my experience it's mostly the not very small but also not very large companies _which have a small set of very excellent programmers_ which do so, with some tech lead spearheading it and having the skill (but not time) to pull it of just by themself. But in larger companies this kind of team structure is rare, fleeting and if it exists most times focused on other more core business areas. I mean in a start up you might find people with skills they could get highly payed for working for a fraction of their salary due to various freedoms and work atmosphere aspects, so you might have an excellent skilled person you can put (or which puts themself) on working on such UI tasks. But in a large company you have this rarely, most highly skilled people there are also highly payed and in turn to expensive to put on such tasks which on paper don't yield that high value (not on a "they can't afford it basisi" but on a "it makes financially no sense" basis). Similar even if that isn't a problem such people tend to be much more constrained by other influences. Then there is the problem that software development isn't that easy to scale (I think most more experienced people know the "onboard a person to gain speed but losing speed" kind of situation). So often approaches to development become more stream lined, with more overhead, and in turn more expensive (but scaling to more devs). At which points considerations for cutting costs come in and in turn the "only one app" decisions is on the table. A good technical example is if you compare (a bit older) react + full reflux with the dart blocks pattern at the core they are the same but the react one is scaling better with many devs while also but in turn also has more overhead by splitting more things apart spreading you logic across all kinds of (standardized) places. Through probably most important companies do not thing in terms of "can we afford it" but in terms of "does that yield enough profits for it to be worth it" (assuming they can afford it).