From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.0 required=5.0 tests=BAYES_20 autolearn=unavailable autolearn_force=no version=3.4.4 Xref: utzoo comp.lang.ada:5851 comp.lang.c++:14381 Newsgroups: comp.lang.ada,comp.lang.c++ Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!uupsi!srchtec.searchtech.com!johnb From: johnb@searchtech.com (John Baldwin) Subject: Re: chief programmer team organizations Message-ID: <1991Jun25.200622.10212@searchtech.com> Followup-To: comp.software-eng Organization: search technology, inc. References: <25587@well.sf.ca.us> <1991Jun23.032353.8718@netcom.COM> <25649@well.sf.ca.us> Date: Tue, 25 Jun 1991 20:06:22 GMT List-Id: 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