ACI got it's first big opportunity in 1998, when we were asked to develop a web-based solution for US Army budget management. We put together a team of three developers of moderate experience. In six months, we were able to field a solution that had hung up a 15-person team for over 2 years.
The reason for our success? We believe we did a better job of working closely with the customer, and communicating in the team.
Today I read a similar blog post,
reinforcing the smaller is better concept with a few studies.
Regardless of the metrics and extrapolations, the general rule holds water:
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.
Other smaller-is-better axioms from our
experience at ACI :
- The average size of a custom software development firm is 5 to 11 full time employees (ACI is currently 15)
- The corporate dynamic changes when a company goes from 20 to 35+; enter middle management and more layers.
- Bigger size = more communication needs = more meetings.
- Software developers HATE meetings.
- Small firms typically need employees to wear more hats. This diversity gives smart developers higher job satisfaction.
- Looking at the public company annual reports, the traditional "economies of scale" don't apply to custom software development.