I agree with some reservations.

A good systems analyst (Note: Singular, not 'design commitee'!), should be able to partition pretty much any system into chunks and allocate those chunks to teams of two, who then exclusively (of other people rather than projects) work on designing and implementing those chuncks.

I say teams of two (up to 4 I think is ok) rather than gifted individuals, as I think even the most gifted individual benefits from and sometimes needs someone to point out his assumptions and blind-spots.

We've all encountered the lone-programmer who can churn out reams of working, tight, efficient code. They often have the ability to juggle several projects simulatenously. However, with rare exceptions, I would rather not be the one that has to go back and try to modify their code.

The whole design-by-commitee thing is a real bug-bear of mine. My favorite example of why software should never be designed by committee, is the english language.

Designed by (one-of) the biggest 'committies' in history, it is an eternally fascinating subject for philosophers, writers, critics, historians et al. (eg. pretty much the whole BA side of learning), but it has no real place except that of defacto-standard in most BSc. subject areas.

This is exampled by the whole 'the sound of ...ough' thing (with tough, though, through, bough, cough, hough, lough).

Personally I don't (yet) see any real reason a large project shouldn't be written in Perl, given proper analysis up front and on-going peer review of the code, but then I'm still learning (Perl).