The concept that smaller teams are more efficient is not new. I've been reading The Mythical Man-Month and it makes this admission right out of the gate. However, as the team gets smaller it also limits the size of the projects it can take on. To that end, what the rest of the book is more or less devoted to is how to do large projects with "small" teams by separating orthogonal tasks and more efficiently organizing the communication structure.<p>In other words, read the book if you haven't already. ;)
I work for a startup now valued at around a quarter of a billion dollars that's negotiating enormous deals with some of the largest providers out there... and our entire development team can fit around a dinner table. In fact, we have significantly more products than we have programmers! Our new CTO, who previously worked at a much larger company, was utterly shocked when he found that our massive product lineup was developed by such a small team.<p>There's also a huge benefit we gain from using existing open-source solutions whenever possible--if you avoid NIH syndrome and stop trying to reinvent the wheel, you can regain a huge amount of productivity.
Growth is tough in general. A team getting larger forces a leader or leaders to emerge. Not everyone can lead or manage. Not everyone takes direction well. All separate skills from just being able to code or design.<p>Larger teams is where politics come in and where I don't want to be. Ideally I only want to work in smaller teams.
Put walls between people, and you'll need to hire more people to coordinate them. Dirt basic common sense, yet one that most organizations have a hard time with. That's a cultural issue. Everyone's allergic to working on tables.<p>Someone once wrote a comparison between DB2's architecture and Ingres. Both are the exact same kind of application built on similar kinds of machines at around the same time. Yet Ingres was built as 4 separate process. The Ingres team was organized in 4 separate groups.
I find the author's assumptions that every idea stems from one individual and must be (ineffectively) communicated to everyone else to be rather strange. I'm all about small teams, and I personally prefer to work alone, but to ignore the contributions that are offered by other members of the team is folly. The "corruption [of ideas] at multiple points" that he mentions could just as easily be interpreted as improvements on the idea.
Though the article was interesting, it's nothing that isn't said a lot: quality communication is necessary and also hard; quality communication between more people is commensurately harder.<p>On another note: the link to hitmeuplater.com was neat. I hadn't see it before and think it's a cool idea.
Software development management is all about balancing "one is the ideal team size" with "this project is going to take 200 man-years." You sacrifice productivity in order to complete stuff in a reasonable time frame.
<i>Communication is actually bad. It inherently involves a loss of information. </i><p>Sounds to me like Avi is in the business of telling rather than being in the business of doing.