The content has been bookmarked!
There was an error bookmarking this content! Please retry.
Posted by Sadek Drobi on Nov 28, 2007
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"
Case Study: IBM's Agile Transformation
SCM best practices for multiple processes, releases & distributed teams
In today’s hyper-competitive world, later may be too late to adopt Agile development and this Roadmap for Success will help you get started. Download "Agile Development: A Manager's Roadmap for Success" now!
The story at the start of Mary and Tom Poppendieck's book "Lean Software Development" tells the story well.
Personally, I have seen this same thing over and over. I worked with a team of five people at a major financial institution that built incredible things, and tool choice was an important factor (this was back in the days of Java 1.2 and 1.3). The team was using Visual Age for Java, and eventually migrated to Eclipse due to some similar approaches to working. Even though this project (code base) was huge considering the number of developers, it would have been ridiculous to add many more people to the team because the level of sophistication of the code would have made it very difficult to manage a bunch of junior people.
Anyone who has read the book "The Mythical Man-Month" understands this concept as well. We can see it in a very simple way:
Imagine that you have just been "given" a software development group consisting of 100 developers. Now imagine that you are given a really important project to work on. Which would be better:
a) Get all 100 people working on the project (with good project management, leadership etc.), or...
b) Find the 7 strongest people in the group who are willing to work on the project (in other words, the seven strongest people that are actually interested in the project) and get them working on the project, fire the rest of them, and spend the savings on giving the 7 people the absolute best tools and environment they need and want, and spending the rest to make them happy/comfortable.
Personally, despite the severity of scenario b), I would definitely bet on it and not on scenario a).
Of course, there are lots of other possible ways of handling this that are much more humane than firing 93 developers, and it would be great to take that middle path, but the two options are meant for contrast.
I think that in the meanwhile people are learning how to write software. The tools are slowly but surely getting better as well (I hate you maven). This means teams are already smaller than they used to be.
The problem with big teams is not so much a lot of developers. THE problem is a lot of roles. Analysists, designers, developers, architects, team leaders, testers, release managers, deputies, project managers, programme managers, product managers, ...
While I believe we're getting much better at development than a couple of years ago we're still struggling to manage all these roles on one project.
This is nothing new. This paper on the subject dates back from 1996:
users.rcn.com/jcoplien/Patterns/AnnalsOfSE.pdf
Having the right team size and makeup is a major part of building quality software. Although, it is so often ignored. 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.
This is the key to me. Not all software can be built with a small team, but in my mind it is always a mistake to start off with too large of a team. Projects should almost always start small - allowing the key building blocks to be put in place.
Hmm, love Poppendieck, but their advice is typically consultant style. Advice is cheap. What would you do faced with the responsibility of the decision? That is the test.
My answer is to create solid interfaces and scale up the teams. You can't go to 7, you have to go to 100 and make it work.
btw, I'm not exactly sure who thinks linux is developed by a small team.
Attila Szegedi talks about performance tuning Java and Scala programs at Twitter: how to approach GC problems, the importance of asynchronous I/O, when to use MySQL/Cassandra/Redis, and much more.
One category of risk that project teams need to ensure they address is business value failure – delivering a product that fails to provide value for the business investor.
InfoQ spoke to the authors of Software Systems Architecture on a couple of new topics, the System Context viewpoint and Agile, which have been added to the second edition.
Alex Papadimoulis discusses ugly code, where it comes from, how to avoid it, and how to get rid of it.
John Davies examines Visa’s architecture and shows how enterprises have architected complex integrations incorporating Hadoop, memcached, Ruby on Rails, and others to deliver innovative solutions.
Sean Comerford unveils ESPN.com’s architecture, what components are used and why, and the current changes the website goes through.
Are there repeated patterns of failure on Enterprise Agile Enablement efforts? Sanjiv and Arlen discuss Seven Deadly Sins to avoid when adopting Agile in an enterprise.
Erik Dörnenburg answers: What is Enterprise and Evolutionary Architecture?, discussing 4 issues: Turning strategy into execution, Ensuring conformance, Where do the architects sit? Buying or building?
4 comments
Watch Thread Reply