An interesting debate has occurred in the blogspace around the issue of team sizes. It started with Reg Braithwaite's post questioning the relevance of powerful languages in a large team environment:
What if programming conventions and closures and meta-programming and expressive type systems and annotations and all of the other tools that give us the power to build powerful abstractions actually don't scale to larger teams?
Reg argues that "productivity drops off a cliff as team size increases" and this assertion is rather consensual. Bob Warfield stresses in his earlier post that "small talented teams crush big teams" not only with regard to productivity but also in quality terms. According to Guillaume who comments on Braithwaite's post, this performance gap is due to the fact that with large teams there are only two choices: "either you code for the lowest common denominator or you end up with a lot of programmers who don't understand the code base." As a remedy, Reg Braithwaite advocates for scaling teams up in productivity rather than in personnel and investing "in tools and processes that are specifically tuned to maximizing the productivity of small teams". This way, it would become possible to build teams around "tools and processes proven to produce working software" rather than "dumbing the tools down to the level of whomever we hired last Tuesday".
Many bloggers argue however that even if very sophisticated software – such as Linux - can be developed by a small team, eventually team growth is inevitable. Chris Winters asserts, for instance, that there is "a huge distinction between creating something and maintaining/improving it" especially since any successful software results in increasing number of costumers and requests coming from them. Nevertheless, according to Warfield, team growth trend is much more related to cultural reasons. Many decision makers are not familiar with the specificity of IT projects and tend to believe that increasing personnel would result in better/faster outcomes. Moreover, career growth aspirations of team members result in hiring more junior stuff, thus contributing to team growth.
If larger teams are inevitable, how can quality and productivity level be maintained? Oftentimes, the solution consists in multiplying the layers of review, which many consider as waste. Commenting on Braithwaite's post, Mike Kucera, who actually does not believe that "having a large team automatically means that the software will be crappy and bloated", insists on the role of abstraction and code readability that help to "figure out the code quickly and get productive maintaining it". Moreover, he highlights that having correct abstraction allows breaking the project down into distinct components that can be developed by several small teams:
With the correct abstractions you can break software down into loosely coupled components, then have a small team focus on each component.
Warfield argues that it is not always possible to break the project into separate components. Hence he suggests cutting the scope of the project because he believes that much of it can "be done away with" without significant impact on costumer satisfaction. This is what according to Warfield accounts for the "art of great software" and allows "a small team [keeping] a product fresh and current for years"
