Re: chief programmer team organizations

[johnb@searchtech.com (John Baldwin)]

John Nagle said in a previous post:

   JN> Real chief programmer teams are very rare. I've never heard of one
   JN> other than in Brooks' book.

   JN> It's organized like a surgical team.  The chief
   JN> programmer personally writes most of the delivered code,
   JN> and everything else is set up to facilitate this.


jls@netcom.COM (Jim Showalter) replied:

  JS> Tommyrot! How on earth is a single human being going to write "most",
  JS> or, for that matter, even a FRACTION, of the code on a project of
  JS> significant size? I'm talking here of things like the multi-MILLION
  JS> line FAA rewrite of the U.S. air traffic control system.


And finally,
In article <25649@well.sf.ca.us> nagle@well.sf.ca.us (John Nagle) writes:

>      But what Brooks was talking about was a job of the size of an
>operating system kernel, a compiler, or a typical shrink-wrapped
>application.


Actually, going back to Brooks' book, what he was talking about WERE
very large systems consisting of many software components.  I think
you are both right and are "looking at different parts of the same
elephant."

I believe the idea was to have a small committee consisting of a cross-
section of the Chief Programmers, who would be in charge of the
architecture of the ENTIRE system.  We all know (I hope) that big
committees never get any work done.  :-)

The entire system might be composed of 20 or more large modules.
For a mainframe's system software, a "large module" might be a
compiler, or the file system, or whatever.  (Case in point, I doubt
that the FAA system is one big executable or even as few as 20.)

The "architects" define the "grand vision" of the SYSTEM, not the
blocks.  They only ensure there is a consistent set of interfaces,
and that the work goes in the right direction.  The real work belongs
to the CPT's: One Team Per Module.  Thus, the chief writes most of the
code IN THAT MODULE.

The problems that can involve this dichotomy between the "architects"
and "the rest of the designers" might be more easily understood by
looking at the following example, also taken from Brooks as he talks
about "Big Oz," the OS/360 operating system, which took 5000 person-years
to develop....

The linker for this OS was the culmination of everything its designers
could possibly know about static overlay linking.  This is remarkably
funny, because the operating system could dynamically allocate system
memory and didn't need a linker with fancy overlay capabilities.  But the
linker team didn't know that, so they did all that work for nought,
and ended up with a linker that was slower than any of the compilers!





Followup's to comp.software-eng, where this really belongs.


-- 
John Baldwin              | johnb@searchtech.com
Search Technology, Inc.   | srchtec!johnb@gatech.edu
Atlanta, Georgia          | johnb%srchtec.uucp@mathcs.emory.edu