This post originated from an RSS feed registered with Ruby Buzz
by Jay Fields.
Original Post: Team Size
Feed Title: Jay Fields Thoughts
Feed URL: http://blog.jayfields.com/rss.xml
Feed Description: Thoughts on Software Development
3 projects ago I worked on a team of 4 developers. We were highly effective and everyone knew the entire codebase. Following that project I was convinced that small, talented teams was 'the way' to build software.
Then I joined my next team: 16 developers.
I was skeptical at first. The team seemed huge. The idea was that the time to market was critical, but there's a reason that The Mythical Man Month was written, right? No one on the team seemed keen on the idea, but we gave it our best effort. The result: A big success.
Of course, there are a million reasons that a project succeeds and a million ways that it could fail, but in the end we did succeed. Not only did we succeed, but I think everyone on the team was surprised at how well the team worked together towards the delivery.
My current project size? 16 developers again.
While some people remain skeptical of large teams, the time to market conditions we are fighting (again) didn't leave us another choice. While there are inefficiencies that are inevitable, I think a lot of us were surprised by the positives that we found.
A large team provides some benefits that I hadn't previously experienced. The Presenter pattern was born on the smaller project, but it experienced trial by fire on the large project. 16 developers all pushing a pattern in every direction can do a lot to see where it fits and where it falls down.
Also, a large team taught me plenty of lessons about testing. On a large team the test suite grows quickly. Keeping all of those tests performing well requires creativity. The test performance lessons that you learn can be reused for the remainder of your career. Additionally, when working on a small team you generally work on tests where you were the original author. However, on a large team it's much more likely that you'll find broken tests that you've never even seen before. Looking at tests from the perspective of a maintainer can make you a much better test author.
Of course, there are plenty of cons with working on a large team. On my last project I was interested in performance of the application; however, I always ended up working on some other aspect of the application. By the time the project ended some time had been devoted to performance, but I hadn't gained any of the experience that the other team members picked up. Some of that is my fault. At ThoughtWorks we often get to pick what tasks we are involved in. But, when there are several interesting things going on at once, you end up having to choose the one that's most important to you.
I still find that smaller teams are more effective when time to market allows a slower pace. However, try not to miss the lessons available from working with a large team if you find yourself on one. Large teams are good for finding language, framework, and developer limitations quickly. Those limitations should be embraced and fixed for everyone's benefit.
Previous Topic
