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.8 required=5.0 tests=BAYES_00,INVALID_DATE autolearn=no autolearn_force=no version=3.4.4 Xref: utzoo comp.lang.ada:5742 comp.lang.c++:14254 Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!sample.eng.ohio-state.edu!purdue!haven.umd.edu!uvaarpa!software.org!blakemor From: blakemor@software.software.org (Alex Blakemore) Newsgroups: comp.lang.ada,comp.lang.c++ Subject: Re: chief programmer team organizations was (c++ vs ada results) Summary: chief programmer teams very sensitive to proper staffing Message-ID: <1991Jun20.143535.27176@software.org> Date: 20 Jun 91 14:35:35 GMT References: <1991Jun18.122812.18190@eua.ericsson.se> <1991Jun18.220609.19103@netcom.COM> <1991Jun19.170047.25064@software.org> Sender: blakemor@software.org (Alex Blakemore) Organization: Software Productivity Consortium, Herndon, Virginia List-Id: In article <1991Jun18.220609.19103@netcom.COM> jls@netcom.COM (Jim Showalter) writes: > One of the most successful Ada projects I'm aware of organized job > descriptions and responsibilities in such a way that a relatively small > number of exceptionally clever people was responsible for the architecture > (as captured in subsystem decomposition and subsystem interface specification), > each subsystem had a talented lead in charge of its implementation (but could > not alter the interfaces, which required an architectural decision), and > within each subsystem there was a team consisting of designers and programmers > (the designers designed package specs [class headers] and the programmers > implemented the bodies). It worked great...and one of the nicest things > about it was that it took the pressure OFF the folks who just wanted to > go program so that they didn't have to PRETEND to be architects. Nobody > felt insulted. Best of all, the staffing requirements when jobs are > set up this way are such that the availability of people is inversely > proportional to the expertise required--the less a person needs to know, > the more of them you hire, making it pretty simple to get the team > assembled (one or two hard-to-find architects, a small group of leads, > a bunch of programmers [many of them entry level and just starting to > learn the Ada language]). 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. This organization alone is not sufficient. I've been on projects at previous jobs with such setups and the upper roles were assigned to those that had been hired earlier, which wasn't the ideal criteria in my mind. They tended to restrict the flow of information between team members, which was great when they were able to create well designed independent work packages - but was a real hindrance when there were problems. I knew one very bright programmer who had unworkable designs pressed on him by the leader of his subgroup. He couldnt totally redesign it without her fighting every step of the way, even though it was absolutely necessary. He finally resorted to making the redesign but leaving a few obvious simple flaws that even she could detect, presenting the design to her for review and asking her help in solving those last sticky "problems". She saved her ego, the software was corrected but the poor guy at the bottom had to suffer through this several times and the lead got the credit when it worked. He would have done better to let the project fail if his goal was to advance in the organization. This project structure is not very forgiving if you place people too high or low in the hierarchy. If you are interested in a biting but accurate satirical treatise on the role of incompetance and hierarchies in large organizations, see the classic book - "The Peter Principle". -- --------------------------------------------------------------------- Alex Blakemore blakemore@software.org (703) 742-7125 Software Productivity Consortium 2214 Rock Hill Rd, Herndon VA 22070