Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!dsacg1!dsacg3!vfm6066 From: vfm6066@dsacg3.UUCP (John A. Ebersold) Newsgroups: comp.software-eng Subject: Re: software engineers Summary: Every project needs a design dictator Keywords: design dictators Message-ID: <1492@dsacg3.UUCP> Date: 16 May 89 16:05:53 GMT References: <854@odyssey.ATT.COM> <10231@socslgw.csl.sony.JUNET> <12701@umn-cs.CS.UMN.EDU> <1320@ruuinf.cs.ruu.nl> <990@syma.sussex.ac.uk> Reply-To: vfm6066@dsacg3.dla.mil.UUCP (John A. Ebersold) Organization: Defense Logistics Agency Systems Automation Center, Columbus Lines: 58 In article <990@syma.sussex.ac.uk> jamesg@syma.sussex.ac.uk (James S Goodlet) writes: >Surely the point to be made is that such bugs occur less in traditional >engineering ventures since: > >1) they utilise disciplines which are reasonably mature and understood - > >2) the designs can quite successfully be decomposed into discrete > subtasks, with the overall design the remit of one or two > individuals. This is in the spirit of "The Mythical Man- > Month"'s pilot/copilot idea, > Software design/coding is not understood and > thus requires either supranormal individuals (rare - if you find > one, keep him/her), or many brains together. And many brains > lead to inconsistencies, and unforeseen interactions - see > mediaeval cathedral construction (the exception being Rennes). In an article titled (I believe) "Slaying the software beast" (No silver bullet) in IEEE Computer, Frederick Brooks wrote about the sad state of software development. Recommend reading. He concluded, as you do, one solution seems to be finding and developing excellent software designers. These people should be given status and perks that high level management is typically given. After reading that article last year and thinking about software that seems to have been done right, leading projects small and large (some of which have turned out better than others) I have reached the conclusion that every project needs a design (and perhaps requirements) dictator. This person should be the best designer in the organization and is not neccessarily the project leader but it would help if she/he were. As Brooks wrote, to paraphrase, The best designers are not always the most experienced. The dictator should have a overall vision of what the software must do and the best way to do it. This is not to say that design trade-offs are not discussed with other project members, but when a decision must be made, the dictator decides. On a related subject... I believe that setting out general design and documentation principles and getting the partitioning bewteen the major portions of a system "right" are the most important things one can do as a project leader. I would make sure similar things are designed in a similar manner (and perhaps generalized) rather than concentrating on the design of some modules that is only needed in one place. Leave those things to other team members. What do you all think? As if I had to ask :-). -- John A. Ebersold at Defense Logistics Agency osu-cis!dsacg1!dsacg3!vfm6066 Unify Corporation System Automation Center Columbus, Ohio 1-614-238-5923 AV 850-5923 Systems with poorly understood requirements cannot be developed in a crunch.