I sat on a panel for a conference last year with fellow owners of “boutique” software development firms. I use the word cautiously, as I’m not completely sure what people mean by boutique in this context, but there are usually implications of small size, specialization, and expertise. One of the more engaged audience members worked for a large, multinational company which created integrated hardware/software products. He challenged us, the panel members, as largely irrelevant to his company because of our sizes. A single project at his company, he pointed out, would consume every single developer in any of our small companies (the companies represented on the panel ranged in size from 10 to 50 people).
I’ve “since learned”:http://greatnotbig.com/2011/03/the-size-of-software-product-development-companies/ that the sizes of the companies on the panel weren’t unusual for our industry. For the NAICS code 541511 (“custom computer programming services”), 85% of companies have annual revenues less than $1.2M. That in turn means that the vast majority of companies employ between 5 and 8 full-time developers. If anything, this data says the companies on our panel skewed toward the larger end of the spectrum for this industry.
Could most of the companies of our entire industry really be irrelevant to this large multinational firm with a huge, unmet demand for software development? Another possibility is the assumption made by our challenger was flawed. Maybe his projects don’t really need to have 30+ developers?
A “study”:http://www.qsm.com/risk_02.html done by consultancy QSM in 2005 seems to indicate that smaller teams are more efficient than larger teams. Not just a little more efficient, but dramatically more efficient. QSM maintains a database of 4000+ projects. For this study they looked at 564 information systems projects done since 2002. (The author of the study claims their data for real-time embedded systems projects showed similar results.) They divided the data into “small” teams (less than 5 people) and “large” teams (greater than 20 people).
To complete projects of 100,000 equivalent source lines of code (a measure of the size of the project) they found the large teams took 8.92 months, and the small teams took 9.12 months. In other words, the large teams just barely (by a week or so) beat the small teams in finishing the project!
Given that the large teams averaged 32 people and the small teams averaged 4 people, the cost of completing the project a week sooner with the large team is extraordinary: at $10,000 per person-month (fully loaded employee cost), the large teams would have spent $1.8M while the small teams only spent $245k. [Update: Team size isn’t necessarily uniform over the calendar duration of the project, therefore you can’t multiply the calendar duration (~9 months) by the cost per person month to get total project cost. The costs I’ve shown use the total person months of effort (24.5 for the small teams, 178 for the large teams) as given in the QSM study.] I can’t think of too many situations where gaining one week in the schedule could possibly justify this cost differential.
If I use the QSM data and compare the cost of a large, internal team of employees versus a small, external team from a “boutique” software development firm, the cost advantage is still huge. Even at a rather high $150/hour, the small team of contractors would only cost $600k versus the $1.8M of the large internal team.
How can small teams be so dramatically more efficient than large teams?
Communication and coordination overhead rises dramatically with team size. In the worst possible case where everyone on the project needs to communicate and coordinate with everyone else, the cost of this effort rises as the square of the number of people in the team. That’s such a powerful effect, in fact, that a large team couldn’t possibly hope to achieve the goal of everyone coordinating their effort. But a small team could.
QSM found another explanation for the huge cost differential between small and large teams. The defect rate for the large teams was five times greater than for the small teams. Defects consume time in discovery, documentation, and repair. That effort is obviously necessary, but doesn’t contribute directly to creating the desired software, and therefore inflates cost without any benefit to the schedule.
I’ll happily accept what’s been said when I can be assured that what the small teams delivered was flexible enough to be extended when the customer asked for new features that weren’t anticipated when the project was started. My experience of small teams (except my own! :-)) is that they deliver unmaintainable and incomprehensible code, incapable of being extended, or even maintained.
This comment talks to the quality of the delivery with is in no relationship with the size of the team, I have seeing large teams delivering poor results, and I have seen small teams (2 or 3 people) delivering high quality. In my experience there is no correlation between the size of the team and the qualityof the delivery.
That’s interesting – my experience has been the opposite – Small teams have generally been more flexible and more up to date with modern frameworks and good OOP practices.
It’s always seemed that the larger teams I’ve worked with have run into “code rot” a lot quicker – as code design tends to get compartmentalized too much into linear code paths that can be managed by separate developers or groups. This is also somewhat systemic when you run into larger companies that develop on platforms like .NET (non MVC) where a developer straight out of tech school sits down and starts writing code. (The kind of companies that measure developer job performance based on how many LINES of code they wrote that year) :-)
@Steve Merrick: that’s where agile comes in!
Don’t get me wrong, I’d be truly happy to see small Agile teams (like mine :-)) outperforming larger teams from big companies. My initial comment asks, in other words, “are we comparing like with like?” It’s always best to check!
It does say the study compared projects of similar size (“100,000 equivalent source lines of code”). So at least they are similar projects in that way. I think its entirely possible for large teams to deliver unmaintainable/incomprehensible code as well, perhaps even more likely because of the noted complexity of communication and coordination (i.e. it takes more time to communicate to everyone the overall structure, style, and design of the project).
I believe smaller teams are more efficient, but I also agree with Steve that it is hard for me to make the leap that we can just divide lines of code by the number of programmers and have an epiphany of efficiency.
I agree with that, but I would also argue that efficiency should never be measured in terms of lines of code.
A huge codebase could mean a very big and complex system as well as it could mean a very badly designed system.
As already noted by another user, large teams pose a big problem for communication. It’s also very common for large project teams to be strongly subdivided in smaller teams with different tasks, which also contributes to the problem.
It is my opinion and experience that smaller teams with engaged individuals performing various tasks and generally helping each other tend to be more efficient and produce higher quality products than bigger teams with bureaucratic barriers for communication.
There might also be a sampling issue (it appears that only completed projects are counted). A large project may be more open to failure in a small team while a large team will muddle through to completion (and likely to further increase inefficiency by adding people to a late project to make it later).
Eric Forsell’s comment below about organization communication overhead also applies. Large organizations can also have restrictive policies meant to reduce complexity that force the use of methods less optimized to the problem. A large organization may also have less hiring and firing flexibility. The longer it takes a misfit to be removed or a good fit to be brought into the team, the longer it will take to complete a project. A large organization may also be less willing to hire a capable but inexperienced worker than a small organization. Only larger organizations can have large teams, and larger organizations may be more inclined to add members to a team because the people are available. (Brooks warned about the temptation to not waste resources.)
Communication overhead can also involve trust/esprit de corps and the potential for unanimity. Even sacrificing one’s own preferences might be easier in a small group (dealing with one large disappointment may be easier to handle than dealing with 20 small disappointments both in learning individual quirks and in frequency [somewhat like less frequent but longer duration interruptions are less disruptive]).
There may also be a weakest link aspect. If task allocation is not matched to performance, then there can be unnecessary waiting for results. In a larger team, there is a greater chance that the worst member is less competent than the worst member of a smaller team.
[…] Small teams beat large teams in software development | Atomic Spin. […]
” large teams took 8.92 months, and the small teams took 9.12 months. In other words, the large teams just barely (by a week or so) beat the small teams in finishing the project! Given that the large teams averaged 32 people and the small teams averaged 4 people, the cost of completing the project a week sooner with the large team is extraordinary: at $10,000 per person-month (fully loaded employee cost), the large teams would have spent $1.8M while the small teams only spent $245k. ”
9 x 32 x $10k != $1.8m, = ~$2.9m; 9 x 4 x $10k != $245k, = ~$360k.
Thanks for the close reading, Scott. I added a clarification as an inline update. Both the duration and costs I’ve quoted are correct according to QSM’s data. The discrepancy in cost you show above has to do with the fact that the size of the team isn’t necessarily uniform over the duration of the project. The cost therefore needs to be calculated from the total person months, not the duration.
I think this is one of the reasons why startups and other small companies can move so fast; the communication overhead is low. But this is not limited to only small companies; the effectiveness of relatively small teams is known even by a number of larger companies. Amazon made famous the idea of “Two Pizza Teams”, where even within that massive company they think that any particular team should not be larger than it takes two pizzas to feed.
I used to work for a small company whose development speed was down to a small team who did no design and no testing. They just hacked until it seemed to work, then they shipped it. All seemed well until the customer asked for additional features that didn’t fit the arrangement (I won’t call it “design”) of the existing code. Their response to *that* request was less than rapid….
You can’t generalize, IMO.
I worked for a small company, in a small team, until recently. Now I’m working for a large multinational company, in a very large organizational unit, split into several teams.
I miss the exquisite coordination we had in the small team. I miss the focus and highly targeted approach to software development even more. While I do admit that the code I’m dealing with now can be considered better in detail, I think we managed to do a better design in the small team, and to respond faster and better to changed requirements.
You know what’s most annoying? The attitude in these large companies is similarly arrogant to that of the person mentioned in the article stating that his project was too big for small teams to manage it.
Given all that data shame all they could do was a histogram with two bins and a giant hole in the middle. This is a poor restatement of Brooks’s Law without showing the quadratic communication relationship between team members vs. the linear productivity gain. Can we have more bins please?
P.S. After a small amount of Google searching, here’s a better study, from the military of all places, showing effective design team size of 5-6, while still retaining effectiveness up to 9.
Thanks for the reference. It looks quite interesting. Haven’t read it yet, but that recommendation of 5-6 synchs with my experience and intuition.
There is actually a very interesting book on project scheduling by Frederick Brooks, A Mythical Man-Month. And it does back up your findings. Communication effort is the main overhead reason. Actually it’s quite surprising that the large team finished first, in the worst case needing 32! communication paths.
Sorry, not 32!, 32+31+..+2+1.
I agree with the article.
I see it this way: If 1 woman can deliver 1 baby in 9 months, can 9 women deliver 1 baby in 1 month?
There is a minimum amount of time that is required for a person to understand a problem to a point of formulating the appropriate solution. Throwing more bodies to a project does not accelerate the understanding of the individual.
And that is key, Big teams (assuming similar capabilities between all members) will not understand and formulated solutions faster than an smaller team. On the other side, small team does not mean “Agile”… there is such thing as Agile as an anti-pattern, cannot go into those iterations without a clue of the problem and its domain, without a base model that explains the problem context and the solution. And this is not a problem only for small teams, big teams have the same problem too.
The question is how well the team understand the problem and the solution, and if the team is large, then that understanding is being diluted between its members. Having a large team satisfy a managerial facade, but is not necessarily for the best of the project.
Big teams don’t understand the importance and don’t know how to use modular design. They are big, so they design big – one big monolithic mess, without any well defined internal structure, without clear separation of concerns across distinct functional areas, with continuously changing internal APIs. When they do aim at a modular and well defined design, they practice design by committee. Small wonder then, that what they produce costs so much more than what small teams produce.
Typically i have found well managed large teams do at least as well at modular coding. Team A builds one module
Team B builds a different one
The big key is the moving of data between them. Good design is the key whether large or small teams are involved.
1. Agile teams I’ve worked with implemented “test-first” coding: no line of production code was written before there was a test (which failed initially, of course) demonstrating it worked. Such implementations more than double the code size but dramatically drop the “Defects (which) consume time in discovery, documentation, and repair.”
Traditionally, test code isn’t kept (sigh), not considered part of the code base nor counted as part of the project team’s output.
2. Agile teams I’ve worked with implemented “pair programming:” no line of production code was written without a partner sitting beside the typist as they discussed what it did, how it would address a test failure and what line was coming next. Such “duplication of effort” gave a GREAT learning curve for those new to the project who soon could train others, or use the instant communication technique of asking another pair a question, since the team was located around that table where they shared pizza!
While TDD and pair programming can improve code quality, that’s no guarantee for design quality. IMO/IME, skilled and well trained small team gain the most in productivity by coming up with smarter, more economic designs. No matter how well designed and coded an app is, it’s still a lot more effort if it needs 1M instead of 100K lines. Usually in large teams the overhead doesn’t come from code duplication, but from lack of effectiveness – many things get implemented which shouldn’t. (I am working for a large company in a large team now, but I have seen this repeatedly in many large companies over the last 15+ years I was working for a small company doing various projects for large companies.)
“To complete projects of 100,000 equivalent source lines of code (a measure of the size of the project)” Bill Gates once said that measuring quality of software in lines of code is like measuring quality of airplanes in pounds. Is the heavier one the better? Not really.
Right. But still, the weight of an airplane is a good measure of cost, provided what’s placed on the airplane is not just bars of lead. So the two apps should be equally expensive, at the same number of lines of code. Instead, the app produced by the large team was several times more expensive. !?
Not really i can write tons of lines of code that do something that a good coder would do in 10 lines. Unless both are working on similar apps/software it isn’t necessarily a good comparison. After all if it took me 100,000 lines of code for this website vs 100,000 lines of code for Amazon’s which really means more.
First thing i must say… Very Nice Article… & Need to thought and implement.
As i worked with the small team and big team as well my experience with small team is really well coordinated and well communicative and better result orientated as well while all these feature are somewhat lacking in big teams.
This matches with my experience. I’ve been around too long and have worked on both large projects and very tiny ones (mostly for commercial products).
Other factors to understand are that it’s harder to hide incompetence within a small team, so the programmers are generally better. Better coders tend towards re-use, thus they might only have to do 100K lines to get to the equivalent functionality of a big team’s 250K. Also, in small teams most of communication is verbal, so there is way less documentation necessary. But I’ve always thought that the strongest difference is that a small team generally has to have a very strong leader, while a large team can get away with a group of people. This means a more focused design and a much more coherent architecture (high-level structuring), both of which feed back into making it easier to write reusable code and thus do way less work.
Paul.
Hi Paul,
I remember when Peter Benjiman first came to IPSA, he wondered how IPSa could do so much with so few while Reuters did so little with so many.
/peter
Hi Peter,
Yes, the difference is very striking if you started with large teams and then get exposed to really talented small ones. IPSA had a great development culture — possibly because in those days APL attracted a large number of smart, mathematically-oriented people with a natural sense of elegance — but things were even more efficient in my last startup.
We just didn’t have time for any procrastination, egos, make-work projects, confused conversations or heavily redundant code. It was all about building the smallest, but best thing that we could that actually solved problems correctly for real people. We quickly learned to be incredibly effective by leveraging all of our work as much as possible, while still managing to be organized and disciplined. It’s not easy, but it’s amazing how efficient software development can be if you have no alternatives.
Paul.
Very crisp and interesting article. I like it!
We also work as a small (rather micro) team of 4. We are all work on the same problem or job at a time (direct/indirect) and its give us the best spirit of team work. It consume more less time as we all have the same goal to meet.
But here it has some drawbacks to, we loose big/Govt. jobs in the name of small infrastructure, SME, etc. etc. even if the job needs a 4-5 peoples team. Banks don’t like to hear/believe too much, even if you have great deal in hand.
But we are happy being small but sharp and keep looking for an Angel.
Thanks for sharing!
I was president of the Southeast Florida Database Developers group in the late 90’s. One of our favorite speakers was Russel Friedland who was smart, opinionated, and funny. He said that a good development team should be able to fit in one car for a trip for beer and pizzas. Looks like that still holds true.
So … I guess that would have made the ideal car for my former team a small van? (Oddly enough, exactly 9 people.)
Statistics that only consider one or two factors (size of team, time to complete) leave out so much critical data that they are hardly useful in making a rational business decision. Who makes up the teams? Who manages them? How much experience do they have both with the technology and the application? That said, I am a strong advocate of the small team. I’ve spent a large portion of my life as a team of one, and that does solve most communication problems. Until you’re over 50 anyway, and one-sharp memory starts to falter on details. I used to say a highly skilled programmer can accomplish in a year what a team of highly skilled programmers can accomplish in two. As Steve Merrick pointed out, some maintainability and expandability discipline is necessary regardless of the team size, but I’ve never seen large teams having an advantage there. I write all my code as if I’m going to have to maintain it myself, and quite often I do end up working on code 10+ years old that is mine, and all I can say is it beats the hell out of working on somebody else’s 10 year old code.
My experience is with smallish teams, but in both large and small companies. I say that it is the company size that has a great effect – and even a small team if in a large company quickly becomes paralysed by external communications blockage – buck passing, endless prevarication when decisions are needed, tedious approval chains where some or other link is always on holiday or otherwise engaged, and so on. In a small company on the other hand, returning to the customer for a decision (internal or external) is usually quick because it is easy to say that a delay will cost more money and that makes a loud noise where it counts. So the small team is able to get on with it, and remains enthused. A small team is much more likely to be motivated to produce a high quality because there are fewer other team members to blame if not. There is less room to hide in a small team!
+1. Exactly what I have seen during the last 15+ years of working as a programmer.
Just a heads up, QSM has more recent research on team size on the QSM blog.
This group size problem applies to company size to. Bigger companies are usually very inefficient compared to small. I’m amazed larger companies are able to stay in business. Maybe political road blocks are put in place by the large companies to freeze out smaller ones? In the end products and service quality suffer and it all might get shipped overseas.
[…] https://spin.atomicobject.com/2012/01/11/small-teams-are-dramatically-more-efficient-than-large-teams… Like this:LikeBe the first to like this post. […]
Would you want your family to fly in an airplane completely designed by a small team or by a large team?
Why or why not?
Discuss amongst yourselves….
:)
The small Lockheed Skunkworks team managed to build some awesome airplanes such as the Blackbird and U2…
http://37signals.com/svn/posts/2578-a-look-at-the-design-process-of-aviation-innovator-clarence-kelly-johnson
[…] https://spin.atomicobject.com/2012/01/11/small-teams-are-dramatically-more-efficient-than-large-teams… Share this:DiggRedditLike this:LikeBe the first to like this post. This entry was posted in Uncategorized by fozbaca. Bookmark the permalink. […]
[…] https://spin.atomicobject.com/2012/01/11/small-teams-are-dramatically-more-efficient-than-large-teams… Share this:DiggRedditLike this:LikeBe the first to like this post. This entry was posted in Uncategorized by fozbaca. Bookmark the permalink. […]
This analysis is kinda silly. Do you really think the types of projects a team of five are producing are the same as a team of 30? Just having the same number of lines of code is not enough to show causation.
[…] in this blog post a study done on 564 information systems projects that seems to indicate that smaller teams are more efficient than larger teams. Small teams were defined with less than 5 people and large teams with more than 20 people. To […]
On this topic I will share a very good quote from the “Scaling Lean & Agile Development – Thinking and Organizational Tools for Large-Scale Scrum” book by Craig Larman and Bas Vodde:
“We regularly coach groups that ask, “How can we calculate how many people we will need?” Our suggestion is, “Start with a small group of great people, and only grow when it really starts to hurt.” That rarely happens.”
As Pavel and several others mentioned, it would be useful to see how the projects compare beyond the lines of code. Did they accomplish similar tasks? Did they enable similar business results? How quickly were they able to respond to changing business needs after implementation? Did they have a similar lifetime after implementation? (defects probably provide a clue to the last question)
Of course this is also affected by other things like whether the original programmers are available throughout the lifetime of the project to reduce learning and maintenance costs. Do larger teams generally stay together and stay involved in one project longer than smaller teams?
In some cases there may be good reasons to have a large team. It can be hard to get enough top-level programmers and training to go around (not to mention good management) when you’re trying to fill out a larger team, but in situations where the cost is outweighed by other factors it can still make sense.
Because of the difficulty of building a good small team some companies might not want to risk it and instead choose a much more expensive but easier approach. After all if the cost of initial development is all that matters they could just assemble a team of offshore freelancers and none of us would be here.
For companies that are sensitive to the cost and ignore the best way, their competitors will eventually show them why it’s better :)
[…] small Interesting tidbit from Small teams are dramatically more efficient than large teams: QSM found another explanation for the huge cost differential between small and large teams. The […]
[…] recently came across Carl Erickson’s ‘small teams are dramatically more efficient than large teams‘ blog post which reminded me of something which my colleague Ashok suggested as a useful way […]
Hi Carl,
It’s amazing that nobody mentioned the number of communications channels that increase dramatically when the team grows.
The number of channels in a team of 4 are: 6
The number of channels in a team of 32 are: 496
[…] Erickson fait l’apologie des petites équipes de développement – je suis convaincu – les commentaires via Hacker […]
[…] Small teams are dramatically more efficient than large teams We would have guessed it anyway, but now there’s […]
[…] Small teams beat large teams in software development This entry was posted in Uncategorized by SiteOwner. Bookmark the permalink. […]
[…] Small teams beat large teams in software development A great article on why smaller teams are able to work so much faster and get more done. This entry was posted in uncategorized by derek. Bookmark the permalink. […]
The reason for all this is very simple. Teams with 32 members are no teams but a group of people divided in different teams.
[…] Bron: https://spin.atomicobject.com/2012/01/11/small-teams-are-dramatically-more-efficient-than-large-teams… […]
QSM is starting a series of posts on team size. The first looks at top and bottom performing teams in terms of duration and effort and finds that team size is the standout difference.
Great data from QSM and more to come.
http://www.qsm.com/blog/2012/top-performing-projects-use-small-teams
Always the same question: Agile vs Quality
I prefere small team’s but each one of us should take responsibility, I think so…
Following the two pizza rule.. I know a guy who is a too large team on his own :))
And some say you don’t learn something new every day.
kerry propper
First thing I must say, very nice article.
I have been working into mobility since couple of years. Though my journey is very short, I must say that this approach work well with the mobile application/software developments, heaving a small team. But my view on the larger software development is, “The team size is positively associates with the software development effort and the software quality”. I have collected few information from the article I have read couple of years back. An empirical study of the impact of the team size on software development effort, they contradict your statement.
Please ignore my comment if doesn’t make any sense.
Aw, this was an exceptionally nice post. Taking the time and actual effort to make a great article… but what can I say… I procrastinate a lot and don’t seem to get anything done.
[…] From https://spin.atomicobject.com/2012/01/11/small-teams-are-dramatically-more-efficient-than-large-teams… […]
After I originally commented I appear to have clicked the -Notify me when new comments are added- checkbox and now each time a comment is added I get four emails with the exact same comment. Perhaps there is a way you are able to remove me from that service? Thanks!
The company size, age and culture has so much to do with this too. From my experience there is no correlation between size of team and quality of code, Iike many others I’ve seen good and bad quality from small and large teams alike.
As a designer, I much, much prefer working on a small team. I used to be shared by multiple Scrum teams. I was constantly rushing around to deliver mockups for the next sprint instead of doing my real job: prototyping, testing, analyzing, recommending iterations…
Now I work on a team of me, a product manager, a developer, and some fancy dude. It is AWESOME! I actually have time to go build and test prototypes with users. My developer never wastes his time because I’ve already vetted whether the designs he’s working on are a worthy idea to begin with. We work at roughly the same pace, so by the time he has pushed code, I have the results of some test to share or new ideas to talk about. We don’t work in sprints, we just collaborate like college lab partners. We sit right by each other; we don’t need scrum meetings because we just …talk.
I’m actually quite annoyed with Scrum because the only people allowed to contribute to the Scrum meetings were the peeps with tasks in the sprint. It majorly devalued my role as a designer. Also, I am annoyed that Scrum assumes design doesn’t take as long as development. As if my job is a cake walk. Pfft. Right now I’m enjoying a 1-1-1 PM-Design-Dev ratio, and I work 50-60 hour weeks. I’m still really busy, but doing things that actually matter.
My new, tiny, not-Scrum-but-very-agile team has been making huge strides in R&D. The executives are just as excited about what we’re producing as what the teams of 10 are producing.
SUCCESS!
I completely agree with the author. Small teams are not only efficient but easier to manage too. However, there should be a mechanism in place to ensure that each of these teams are in sync with activities going on in other teams.
[…] an article about the productivity of small teams compared with huge ones. The original article is here and i suggest to you to take your time to read it; personally I found also the comments a lot […]
The smaller the team, the better, according to my own experience. When possible, a team of one is the best. I noticed that, when the team size grows, they ask the best guys to supervise the work of the other ones. Which means that, instead of programming, these guys tell the other ones how they would do it if they were not busy with something else.
Hi-ya! Thanks for this write-up! I find it hard to unearth awesome data out there when it comes to this material. thank for the content!
Porque tienes 2 servicios de 2 horas cada uno gratis al año de un electricista para tareas eléctricas en tu vivienda. En excepcionales circunstancias en las que el tiempo de reparación excede a las 2 horas nos comprometemos a entregar presupuesto previo gratuito para cualquier reparación. Reparaciones urgentes en electricidad, 24 horas al día, los 365 días al año, con 2horas de mano de obra y desplazamiento gratuitos y un año de garantía. El servicio OkLuz Asistencia Plus entra en vigor cuando se activa el contrato de suministro de energía. El descuento del 50 sobre la cuota del servicio tiene una duración de un año desde la fecha de inicio de contrato.
This is awesome article about the productivity / performance of Small Vs. Big Team.