Xref: utzoo comp.lang.misc:7508 comp.object:3231 Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!wuarchive!cs.utexas.edu!sun-barr!lll-winken!ubvax!igor!rutabaga!jls From: jls@rutabaga.Rational.COM (Jim Showalter) Newsgroups: comp.lang.misc,comp.object Subject: Re: Software "Engineers" Message-ID: Date: 18 Apr 91 05:18:09 GMT References: <3844@ssc-bee.ssc-vax.UUCP> Sender: news@Rational.COM Followup-To: comp.lang.misc Lines: 81 > (Real) engineering is based upon certain (perceived to be unmutable) physical >laws, such as f = ma. Basing engineering upon these laws yields methods which >may be applied, in the same manner, to a set of engineering problems. For >instance, calculating the amount of heat loss through the walls of a >residence is always a fixed relation between given variables, such as: >wall thickness, insulation used, etc. Therefore, the solution is always >arrived at via an accepted mathematical method. The laws don't change, but I submit that there are at least several different engineering approaches to any decent problem in any engineering discipline. Do you use simulation? If so, what kind? Do you use finite element analysis? CAD? Models? Wind tunnels? etc etc etc. A good engineer is familiar with the standard tools and techniques, and is able to apply one or more of them to a particular problem to achieve a proper result. In what way does software differ from this? The "physical laws" of software encompass things like the order of a binary search, etc. The various tools and techniques include OO, functional decomposition, structured analysis, information modeling, system analysis, etc etc. A decent software engineer applies such tools and techniques to a set of requirements to produce a solution. Seems indistinguishable from any other engineering discipline. > To test for competency among engineers, one presents a problem such as >that outlined above: how much heat loss through walls with the data below? >Every compotent engineer will arrive at the same conclusion through (roughly) >the same methods. So, for software ask what the space/time behavior of some algorithm is. Same difference. >There is no one correct way to write, for instance, a database. There is no one correct way to design a skyscraper. > How does one test a software "engineer" for competency? In engineering, one >takes classic problems, changes the important variable values, and asks >an engineer to solve them. "Given the following design, adapt it to now work in a distributed computing environment. Show all work." >In software development, there are far fewer >classic problems, Strongly disagree. The problems have been around forever: database, MIS, real-time, blah blah blah. The sad thing is people keep starting from a blank sheet of paper every damned time they build anything. >and, worse yet, none of the problems has one accepted >mathematical method for solving them. What is the accepted mathematical method for designing a drawbridge? There are certainly methods for analyzing stresses, etc. But there is no cut-and-dried way to just stamp out the drawbridge design. If there were, we'd design one drawbridge and be done with it for all time. >Testing for competency among >software developers is a much more difficult task than testing for >competency among (real) engineers. I do not believe you have supported this claim. All of the answers I've seen basically boil down to "Software engineering is not like other engineering disciplines because it is inherently different". This is just tautology, but I don't believe it for a minute. There is a cultural belief among many programmers that what they do IS in some way different from what other engineers do, but that is just the ego of fragile wannabee "artistes" speaking up. Fundamentally, there is nothing more or less difficult, more or less creative, more or less rigorous, more or less amenable to metrics, more or less amenable to process control, etc etc etc between software and any other engineering discipline you'd care to name. Software is just an immature field. And it shows. -- * The opinions expressed herein are my own, except in the realm of software * * engineering, in which case I borrowed them from incredibly smart people. * * * * Rational: cutting-edge software engineering technology and services. *