Path: utzoo!attcan!uunet!mcvax!ukc!icdoc!syma!jamesg From: jamesg@syma.sussex.ac.uk (James S Goodlet) Newsgroups: comp.software-eng Subject: Re: software engineers Message-ID: <990@syma.sussex.ac.uk> Date: 15 May 89 15:14:09 GMT References: <854@odyssey.ATT.COM> <10231@socslgw.csl.sony.JUNET> <12701@umn-cs.CS.UMN.EDU> <1320@ruuinf.cs.ruu.nl> Organization: Univ. of Sussex, Brighton, UK Lines: 60 Distribution: Keywords: Summary: In article emuleomo@yes.rutgers.edu (Emuleomo) writes: >Have you ever seen a civil engineer debugging a bridge after it has been built? Indeed, the Erskine bridge over the River Clyde in Glasgow (Scotland) was heavily "debugged", notably with changes to the railings at the sides of the bridge to change its behaviour in cross winds (I believe the bridge was resonating slightly). Not on bridges but related, consider the infamous M25 motorway around London, England. This was repaired (several thousand tarmac joints replaced) *before* it had even opened. And now, only a few years after it was completed, it is being extensively widened. These are real bugs. 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 - there is a science (engineering discipline if you must) in bridge building - much of it is painting by numbers now. Software coding and *design* is not understood, regardless of the claims of proponents of structured design methodologies. These methodologies serve a useful purpose in supporting the book-keeping requirements of the task - they lend nothing to the assistance of the creative effort of the design team. Thus "software engineering" is an art, not a science. 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, where the design is specifically the product of one or two individuals, with other team members playing supporting roles. (This is often given as the reason for the comparative success of small software teams.) In a traditional engineering discipline, the knowledge required for the design task has been made accessible through centuries of empirical investigation and analyses of results. This knowledge can be used by (held within the mind of) one or two principal engineers on a project, thus leading to internally consistent, cohesive designs. 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). James (*** please note, no offence is intended to structural/civil engineers - in order to "paint by numbers", they need to attain a high level of proficiency in an esoteric domain ***) -- School of Cognitive & Computing Sciences, Talk: +44-(0)273-806755 x2407 University of Sussex, JANET: jamesg@uk.ac.susx.cogs Brighton BN1 9QN, UUCP: ...!mcvax!ukc!cogs!jamesg United Kingdom ARPA: jamesg%cogs.susx.ac.uk@nsfnet-relay.ac.uk