Small Teams

The pain caused by broken builds is usually inflicted, to one degree or another, on the entire development team working on the same code line. Consider the case where a build failure wastes an hour of time for each impacted developer, and that any given developer will break the build once every 50 working days. If the development team is comprised of 100 developers, that would result in about 2 broken builds a day, as well as about 200 wasted developer hours (25% of the team's time).

However, breaking up the large team into 10 groups of 10 will result in wasting only 20 developer hours (2.5% of the team's time). In the simple view, the team could accomplish the same amount of work done with 22 fewer developers. Consultant-based projects become cheaper, and independent software vendors (ISV) are able to devote more effort to research projects. This technique speaks to the second pillar of pain free building: limiting the impact of failed builds.

Small teams are a great practice, even without considering build issues. Most Agile methodologies recommend small teams because smaller teams experience fewer communication problems and tend to be more effective.

One of the first questions people ask is: how do we split up a large team? While there is not set rule, there are some helpful practices to use as a guide. Two great approaches to answering this question are detailed in the Componentized Projects and Team-based Development Streams sections.