> I have always taken the viewpoint that a software project is better off
> with a smaller number of more competent programmers. The difficulty of
> managing N people for a given value of N is *certainly* not made easier
> by having less than fully competent people, if anything it is made
> harder, and the difficulty of managing N people climbs rapidly as N
> climbs.

I have also found this to be the case in every large project I have been on.
The project starts out with a small number of quality software engineers who
layout the top level design implementation based on the requirements. They
also set up program and documentation standards (we have always used a
real-time structured analysis approach).

The project then "staffs-up" with anyone they can get their hands on to do
the bulk of the coding. Unfortunately, the group is too big and higher
priority demands too numerous for the program leads to keep track of whether
these people are adhering to the standards set up. These people supposedly do
low level code testing.

With the bulk of the code written, the project staffs back down to the same
people it started with who are left to get the system software working
together. Unfortunately, much of the code is not written well, having bugs
and inefficiencies.

The point is that we would have done better staying with the 8 or 10 people
we started with - even if it meant taking a few extra months at the code
phase.