jerbil@ultra.com (Joseph Beckenbach {Adapter Software Release Engr}) (06/21/91)
>> Alex Blakemore <blakemor@software.software.org> > Ron House <s64421@zeus.usq.EDU.AU> >>This makes sense and sounds like it can work well. It's really just >>the chief programmer teams from the Mythical Man Month by Fred Brookes. >>One obvious caveat - you really better have the right people >>in the chief programmer roles or you are sunk. >The book "Software that Works" by Michael Ward recommends against this for >exactly the reason you mention, among others. He feels that the programmers >must be involved in design, and that design/programming should alternate, >rather than one coming first in a big chunk followed by the other. >That's my potted version, anyway. Not having read Mr. Ward's book, I cannot say how to interpret his experience. Having read Mr. Brooks's book, and drawing on my own experience, I can say that Ron House seems to have fallen into a common misconception -- in a project requiring architects, once the architects are finished the design work is done, and no-one else can do any design work. This view is a myth, since it extrapolates the huge-scale software effort from the small-scale software effort. One can as successfully extrapolate from a doghouse to a city block in downtown Manhattan. The architects exist to provide a grand unifying vision for a project, so that there is a framework for the rest of the work to proceed. The teams and team members who must create the darn thing have few exact specifications, no clear idea what trade-offs will be necessary to meet high-level designs, and no limitations on exactly how they will get there. If going from there to being ready to code isn't "design" in its own right, then by that usage of the word there is NOBODY who does design in projects smaller than five people, in any field of endeavor. One MUST have good people at the top. This does not mean that all the thinking is done at the top, just the broadest strokes of the brush. And note that Brooks's project had several HUNDRED programmers working at any one time; without such a division of labor, the project would not have been possible. Joseph Beckenbach -- ---- Joseph Beckenbach jerbil@ultra.com 408-922-0100 x246
johnb@searchtech.com (John Baldwin) (06/26/91)
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