Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I work for a company that is moving heavily into mobile. We find the majority of our customers use our mobile app pretty regularly.

We have tons of things we want to add to it -- as well as to deliver all these new features on Andriod- and iOS-native apps.

But I wonder how big we could possible make a mobile development team without making it too big to be practical. Can we have a mobile team that's 5 people? 10? 50? 100?

If it made sense for us to build that many new features, from an Engineering standpoint is it practical? Or is there some limit of the amount of Engineers that could support a single app (across multiple platforms)?

share|improve this question

closed as primarily opinion-based by gnat, DougM, thorsten müller, Robert Harvey, Dynamic Jan 28 at 21:23

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise.If this question can be reworded to fit the rules in the help center, please edit the question.

2  
I'd suggest reading the Mythical Man Month. In particular, the surgical team essay within it. Too big a team gets into a diseconomy of scale. –  MichaelT Jan 23 at 17:01
    
Thanks for the suggestion. I actually read that book a number of years ago, but maybe I should go back and re-read. I'm actually hoping to get some practical size estimates based on people's experience building apps. –  Kevin Bedell Jan 23 at 17:04
    
Do you plan on growing more than one dev at a time? And why can't you have more than one team? –  JeffO Jan 23 at 19:10
    
Your team can be as large as your source control system can handle. –  paulkayuk Jan 24 at 9:53

1 Answer 1

up vote 3 down vote accepted

The upper limit for any team size is dictated by the governance in place within the company and the individual projects. As the team grows larger, more governance is required in order to continue to remain productive.

Communication without governance grows by an exponential rate (n*(n-1)) because each team member needs to check in with every other team member in order to introduce significant changes. Remember that communication paths are one-way in this case.

Small development teams get away with less communication because a team of 3 developers only has 6 communication paths.

A=>B; A=>C; B=>A; B=>C; C=>A; C=>B

A team of 4 developers has 12 paths.

A=>B; A=>C; A=>D; B=>A; B=>C; B=>D; C=>A; C=>B; C=>D; D=>A; D=>B; D=>C

Now this is usually manageable for small projects, but things start to break down when the sheer number of communication paths gets to be too much.

How much is too much? It depends. A well modularized application staffed by top-notch A-players can probably sustain a lot more developers with less (formal) governance then a poorly structured application with neophyte developers.

The point of the governance is to eliminate some of the communication pathways, and this is where specialization comes into play. Developers start identifying themselves as "front-end" or "back-end" or "database" or whatever type developers. It usually occurs as the application gets too large for any one person to really understand.

Governance comes into play because Front-end dev Sven normally never needs to talk to the database folk, and he very rarely needs to talk with Todd who is the team lead (or architect) for the back-end devs, and Sven almost never needs to talk to Jane who rules the database layer / roost. Governance allows each developer to work within their normal sphere and minimize who they need to coordinate changes with.

So with a team of 12 developers, instead of having 132 communication paths, you have 3 groups of 12 communication paths plus 6 more communication paths between the 3 team leads.


So that was some fun, fancy-dancy, high-browed intellectual thoughts about teams. Let's use your specifics for a little less abstraction.

You want to have iOS and Android apps. That's fine, that's two teams there.

You have a ton of features you want to add. That's fine too. You're going to need teams for UI work, web services, database changes, etc ... You now have more groupings to use to limit the total number of communication paths with.

Don't forget to designate folk to coordinate with other teams. Some companies call these architects, other places call them team leads. Call them what you want, just make sure that you don't duplicate too much effort between various teams. Again, governance and process play a critical role here so that people focus only on the area they need to change in order to code up the necessary features.

share|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.