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.

Don Wilde
"There's more than one level to any answer."

In reply to Re^2: Interesting insights from Software Estimation: Demystifying the Black Art by samizdat
in thread Interesting insights from Software Estimation: Demystifying the Black Art by tilly

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.