One of the advantages of big teams is that you ask for a few books and you get back "Investing in our people is always in ____'s best interests." Ordered.

In regard to the productivity of small teams, I spent most of my career as "it". I think it surely has both advantages and disadvantages. One disadvantage is that you don't get valid design and code reviews, but one of its advantages is that you need fewer of them.

I'll second the personality and politics caution. My very first programming-only job was 8051 assembly coding for a handbuilt wire processing assembly line. The guy who hired me started out being quite egotistical about his skills, but ended up getting quieter and quieter as my skills surpassed his. I won't say that I _was_ better than he was, but since I was learning this from scratch, it was obvious that I was going to be pretty good quickly. It never turned into a problem, but it could have. He was having difficulty not being the only star. I don't think that's an issue only for small teams (!!!!), but it's definitely more of a showstopper potential for them.

I heartily second tilly's point that small teams can do a lot with Perl or other dynamic interpreted languages. There are times when teams (because of management or programmer stupidity) choose Java, say, because it's the 'next wave for Enterprise development', and end up killing the project and the company because of the design and CPU overhead. I'll need to read McConnell's book to get to the source of the thread, but I'll agree that an awful lot of projects that are coded in C or C++ or Java had no need to be done that way and would have been better done in Perl. A lot of this 'embedded Linux' stuff has no need to be compiled C, and we'd be better served to get it out the door more quickly than to save a few cycles of CPU. We're definitely seeing every one of tilly's concerns about big teams here, from personality conflicts to API problems to inefficiencies to crappy programmers hiding in the weeds. I've slipped in a few scripts that have ben well received, mostly for generating C header files and array declarations early in the build, but the truth is that there's very little code here that couldn't be all Perl.

Food for thought. Thanks, tilly, for the link and the commentary.