By Craig Buckler

Why Larger Teams Do Not Result in Faster Development

By Craig Buckler

One of the biggest mistakes software companies can make is to assume that more developers will result in more rapid product releases. It doesn’t. This initially seems illogical, however, the law of diminishing returns applies to most industries. And there’s truth to the old adage about too many cooks…

Software development is an unusual and complicated process. Unlike other forms of manufacturing, there is an infinite variety of outcomes and every part of the process is integrated. Seemingly difficult processes can be quick and simple to implement, whereas easy functions can have hidden complexity.

However, one of the primary reasons why more developers != faster development is that a larger team increases communication complexity. When a component is created or modified, it has an impact on other parts of the project. For example, assume developer A is writing a database connectivity class and decides to make a simple change — such as swapping the order of two parameters.

  • In a team of 1, the developer can make the change without communicating with anyone.
  • In a team of 2, the developer must inform one other person.
  • In a team of 3, there are two others to inform.

Therefore, in a team with N members, a developer must contact (N-1) others about the change. Since any team member could make a change at any time, there must be N * (N-1) lines of communication. However, since developer A communicating with developer B is the same as B talking to A, we can divide that total in two. Our final equation:

C = N (N – 1) / 2

Where N is the number of team members and C is the total lines of communication.

Unfortunately, these lines of communication increase exponentially with every additional member. A team of 5, has 10 lines. A team of 10 has 45 lines. A team of 20 has 190 lines. And a team of 100 has 4,950 lines.

It doesn’t matter how you operate your communication channels. Every developer must decide whether a change affects their code and implement updates accordingly. The complexity of software development then raises other issues:

  • has everyone received and understood the change?
  • do some team members require further assistance?
  • does developer A need to justify the update to other team members?
  • has the change been tested across all systems?
  • does the change lead to a cascade of changes in other components?

It’s not just code changes. Any project decision must be dispersed throughout the team.

Complex projects take time and throwing resources at an over-running schedule won’t necessarily help. You may need to accept that the schedule wasn’t realistic from day one.

  • creastra

    I like working in teams of 3. Designer, Developer/Programmer, Copywriter. That sort of thing. Depending on the size of the project I may pull in 3 contractors instead of 2, but anything more than 4 is iffy. Thirteen years of doing this and I’ve found 3 to be the best number. You have a small group, everyone is specialized so no one feels like their toes are being stepped on, and 4 means any voting within the project is pretty cut and dry.

  • fbanyai

    I had a manager that always told “9 pregnant women together don’t give birth to one baby in 1 month”. :)

  • peppolypus

    @fbanyai: lol, it’s true! :D
    I also think 3 it’s a good match, especially if the other two are always the same two :), communication gets easier over time, and you kind of develop a personal and unique way of communicating with each other which, in my opinion, reduces the “noise” on the comminucation… it also leads you to develop you own tools, like team log system, to do list, version control and so on…
    On the other hand there are times when having one person per field (ie just one developer, just one designer…) just won’t make it. And this is the exact situation where I’m stuck in and I found out that it’s really difficult to get someone else used to you “communication system”
    Maybe an initial training would be the answer?

  • The point that is given in the article is correct, though I dont agree completely with that its as difficult as mention to work on a larger team.

    As long as the project description is properly laid out (smaller tasks) and divided across the team and source control is used its not that big of a deal.

    Though as mentioned, the larger the team get, the harder it will be to keep everything running smooth unless you divide them into smaller teams each having responsibility of one part of the project.

  • yousif basim

    i liked what your manger says

  • It does not actually quite work out like that. As teams gets bigger you appoint managers to control smaller teams. So with 90 developers, you higher 10 managers so that there is 45 lines for each team, plus 45 for the 10 team managers. Which is 495 over all. At least that is what they are telling us in the project management course I am doing at university.

  • XLCowBoy

    It’s okay to have a larger team, but the critical factor of a knowledgeable manager becomes more and more apparent as the size increases.

  • Although I totally agree with the article, there are projects that can not be completed with small teams.

    What you should do then is to separate the whole project into smaller dinstictive components and have a small team, of 3-5 people tops developing each component, while a manager-coordinator for each team should take care of how each component should integrate with the others forming the complete system.

  • Michael K

    Larger teams CAN result in faster development times. They don’t always do, and most of the time, it depends on the nature of the project. The most important factor is the organization of the team and the breakdown of the project.

    Your equation cannot apply in a real world scenario and is simply ineffectual for this simple reason: Not all members of a team need to communicate with each other over changes in the project. This is a very important consideration your article has overlooked and that makes it somewhat erroneous. I have actual examples (in multiple disciplines) I’d love to share – but that would result in a full article rather than a comment.

  • Lachlan

    In case nobody has read it, The Mythical Man Month is an incredible book about the mechanics of teams of engineers. It talks about the formula presented above in some detail.

    It was first published in 1975. You’d think in the intervening 35 years we might have absorbed some of these basic facts, wouldn’t you?

  • @Lachlan I think the industry has improved since then. But yes that is a great book. I would also recommended it, as it was recommended to me when I was doing a team project at university that went very sour – I got the lecturer to divide the marks at the end such that 3 of the team members failed the project and myself being the 4th did very well. Not a nice experience.

    Some interesting reading is always the CHAOS Report

  • Jonathan Lambert

    This is the infamous — and extremely well known — the nine mother problem. No, it’s not sexist, it’s purely a reference to biology, and it’s a common phrase in Silicon Valley. The phrase is: “If one mother can have a baby in nine months, why can’t nine mothers have a baby in one month?”

    Because it’s not… the… way… that… works.

  • I like to work in teams but not particularly large ones unless the project warrants it. I find for the size of the projects we’re doing a team of 3 or 4 is sufficient. We usually need a couple of techies to work out the logistics (me + 1), a designer to come up with the presentation and often the flow of information, sometimes marketing/copy writing and even a project manager to push the whole beast through to completion.

    I’ve worked on projects with a large number of players but it seems that sometimes if the group is too large some of the stakeholders just have meetings to schedule more meetings because they really don’t have any other purpose.

  • Adomovic

    Nice, but you need to do part 2 where you let us know what would be the best approach to creating a team for a project especially when the project is huge. Do you create segments of teams or sub teams, what would be best.

  • Another adage might be – if 10 men with spades can dig a hole in 10 days, can 100 men with spades dig the same hole in 1 day?

    Of course they can’t, because 100 men would never be able to get near the hole all at the same time.

    It’s the same reason why marxist distribution of labour doesn’t work – if 100 men with spoons can dig the same hole in the same time, then it creates 10 times as much work. But again, 100 men could never get near the hole, so most of them would spend most of their time standing around drinking tea.

    Sound familiar? :D

  • callmestupidbut

    Working within a marketing team for an SME, in my role I account for designer, developer, marketing and SEO all at the same time. This works well for me as I know exactly what’s going on with our sites. I do have input from others on copywriting and photography, but generally all web stuff is my responsibility. I can see why others like to work in teams, but I find it hard to let go of jobs and trust others to do things as I would do them – perhaps I need to learn!

Get the latest in Front-end, once a week, for free.