Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!decwrl!sun-barr!apple!shebs From: shebs@Apple.COM (Stanley Todd Shebs) Newsgroups: comp.software-eng Subject: Re: software engineers Message-ID: <1736@internal.Apple.COM> Date: 9 May 89 17:27:23 GMT References: <854@odyssey.ATT.COM> <10231@socslgw.csl.sony.JUNET> <12701@umn-cs.CS.UMN.EDU> <4951@pt.cs.cmu.edu> Organization: Apple Computer Inc, Cupertino, CA Lines: 37 In article <4951@pt.cs.cmu.edu> jwb@LINDENTHAL.CAE.RI.CMU.EDU (John Baugh) writes: >In article <12701@umn-cs.CS.UMN.EDU> smiller@umn-cs.CS.UMN.EDU >(Steven M. Miller) writes: >>Software can be orders of magnitude more complex [...] > >As a once-practicing civil engineer, all I can say is `baloney'. >(BTW, I have also worked on software projects of > 100,000 lines >of Fortrash, so I at least have some experience on both sides.) >Visit your friendly neighborhood consulting AE firm to get an >idea of the number of people, specifications/requirements, etc. >that must be coordinated in the design and construction of a real >engineering product -- it's staggering. Comparing numbers of people or pounds of documentation is not necessarily valid. My personal impression from working alongside assorted engineers is that individuals tend to be more specialized in the traditional engineering disciplines. So for instance you might have somebody on a project that is concerned only with bolts, or electrical connectors, or maybe even with only a single oddly-shaped part made by a subcontractor. Many (most?) software people are in the opposite situation - they have to be concerned about all aspects of a 50K line program, and they rarely have the leisure to really understand the code proper, the design, the limitations, the consequences for other parts of a system, and so forth. Just imagine how different things would be if you only had to be responsible for, say, 1,000 lines of code and could spend a year working on it. You spend time analyzing it in depth, you could polish the documentation, you could tune it for optimum performance. Unfortunately such a situation is rarely possible in today's environment... Getting back to comparing bridges and programs, a more valid method might be to compare the information content of a program to that of a bridge (more accurately, to the size of its description). This would factor out sheer volume; 10,000 identical bolts aren't much more interesting than one bolt, ditto for code that is replicated in different parts of a program. Seems like at least one theorist would have looked at this in the past... stan shebs shebs@apple.com