csm@garnet.berkeley.edu (Brad Sherman) (02/06/88)
There seems to be a perception among programmers that current software development is not really "engineering." What do "real" engineers do that we do not? Is there anything in programming that is analogous to the term "tolerance" in engineering? Brad Sherman - (You See Bee) I don't know what I like, but I know art when I see it.
apte@duke.cs.duke.edu (jitendra apte) (02/07/88)
In article <6879@agate.BERKELEY.EDU> bks@ALFA.berkeley.edu (Brad Sherman) writes > >Is there anything in programming that is analogous to >the term "tolerance" in engineering? > how about the following : designing and writing programs that are expected to yield acceptable results most of the time, but not guaranteeing good results for all possible inputs. a typical attitude while writing programs to solve problems which are known to have very time consuming exact solutions, but which can probably be solved to near exctness using heuristic methods. (np problems and the more expensive p problems). jitendra apte.
geoff@desint.UUCP (Geoff Kuenning) (02/07/88)
In article <6879@agate.BERKELEY.EDU> bks@ALFA.berkeley.edu (Brad Sherman) writes: > Is there anything in programming that is analogous to > the term "tolerance" in engineering? It seems to me that heuristics are analogous. -- Geoff Kuenning geoff@ITcorp.com {uunet,trwrb}!desint!geoff
kent@xanth.cs.odu.edu (Kent Paul Dolan) (02/07/88)
In article <6879@agate.BERKELEY.EDU> bks@ALFA.berkeley.edu (Brad Sherman) writes: > > > >There seems to be a perception among programmers that >current software development is not really "engineering." > >What do "real" engineers do that we do not? Real engineers build bridges that work when delivered. >Is there anything in programming that is analogous to >the term "tolerance" in engineering? If by tolerance you mean the kind you measure with micrometers, sure. That is what all those convergance criteria are in numerical analysis. If you mean the twelvefold over strength needed wooden beams in some old houses, then again yes. We do it when each routine checks its inputs, even when they are created within another subroutine of the same program, when we check the return code on the "close()" file command in C, which is folk rumored never to fail, but has actually been known to do so. We call it paranoia! ;-) > > Brad Sherman - (You See Bee) > >I don't know what I like, but I know art when I see it. Kent, the man from xanth.
svb@teddy.UUCP (Stephen V. Boyle) (02/08/88)
In article <6879@agate.BERKELEY.EDU> bks@ALFA.berkeley.edu (Brad Sherman) writes: >current software development is not really "engineering." > >What do "real" engineers do that we do not? > Since my background is Chemical Engineering, I'll use examples from that field. In Chem. E., when I needed to design a heat exchanger, I used a set of refer- ences that told me what the constants were for the materials the heat exchanger was going to operate on, and the *standard* design equations for the exchanger itself. I don't mean to imply that every problem in Chem. engineering (or any other engineering) design is easily and completely reduced to "look up the numbers", but it sure happens a heck of a lot more than when I'm writing soft- ware. Sure, there are some examples of "canned" routines and algorithms (quicksort is what immediately comes to mind), but in general, unless I, or someone else in my engineering group has read or remembers and makes known a solution to a past problem, I'm doomed to re-create the solution. The closest thing I can think of to what I consider "real" engineering in software are the user- interface building tools that let you quickly design a screen layout and which then generate the corresponding code. I guess what I consider the critical difference is the ability to put together little pieces of the problem that are relatively well known, without having to generate a custom solution for every application. This would allow software people to spend time on what makes the current application unique. Now before people get their keyboards cranked up, I want to make it clear that I am aware of algorithm and code libraries, but they are incomplete solutions to what I am describing. (There is no "Perry's Handbook" for Software Engineer- ing.) Plus, none of the above even whispers about scheduling. I'm not going to get into that tar pit, I've depressed myself enough for a Monday morning. -- ... !{decvax,linus,wjh12,mit-eddie,masscomp}!genrad!svb Steve Boyle GenRad Inc, Production Test Division MS 06, 300 Baker Ave, Concord, Mass. 01742
mac3n@babbage.acc.virginia.edu (Alex Colvin) (02/08/88)
> >What do "real" engineers do that we do not? > > Real engineers build bridges that work when delivered. Real engineers rearely attempt to convert a ferry boat into a bridge. Software engineers do it all the time.
hollombe@ttidca.TTI.COM (The Polymath) (02/09/88)
In article <6879@agate.BERKELEY.EDU> bks@ALFA.berkeley.edu (Brad Sherman) writes: >There seems to be a perception among programmers that >current software development is not really "engineering." > >What do "real" engineers do that we do not? Engineers typically work with known quantities and predictable results. What they're doing has usually been done before and is well understood. (e.g.: We've built a lot of office buildings. We know how long it takes to put up girders and floors and wiring. There are tables of beam sizes and riveting codes, etc.). That's why PERT charts work so well with engineering projects. Software designers/builders, on the other hand, are usually doing something that hasn't been done before. If it had been, why do it again? Why not just copy it? (It's a bit difficult to copy an office building (-: ). Software is a more creative, seat-of-the-pants endeavor than "hard" engineering. There are no tables of beam strengths or fluid flows to refer to. There are standard references for limited types of algorithms and these generally are copied rather than built from scratch. But the reason for any new software project is to make a computer do something it hasn't done before. There are many unknowns in such an undertaking, which is why the PERT model doesn't fit software development very well. There's still some art to it. -- The Polymath (aka: Jerry Hollombe, hollombe@TTI.COM) Illegitimati Nil Citicorp(+)TTI Carborundum 3100 Ocean Park Blvd. (213) 452-9191, x2483 Santa Monica, CA 90405 {csun|philabs|psivax|trwrb}!ttidca!hollombe
decot@hpisod2.HP.COM (Dave Decot) (02/09/88)
I agree that the distinguishing characteristic between what this "industry" does and engineering is the general unexpectation that what is produced will perform exactly as specified. I think independent software validation organizations could make pots full of money if they became well-known and reliable. Something like UL (Underwriters' Laboratories) for software. Dave Decot hpda!decot
ok@quintus.UUCP (Richard A. O'Keefe) (02/09/88)
In article <4618@teddy.UUCP>, svb@teddy.UUCP (Stephen V. Boyle) writes: > Sure, there are some examples of "canned" routines and algorithms (quicksort > is what immediately comes to mind) Oh dear, I do hope not. Everybody seems to be hypnotised by the NAME "quicksort". If you check a good reference (Knuth AofP, for example) you'll find that quicksort is ***not*** a good general-purpose sort! For a generic sort (comparison is a caller-supplied function, not a single machine instruction selected at compile-time, or is string comparison) merge-sort beats quick-sort handsomely.
svb@teddy.UUCP (Stephen V. Boyle) (02/10/88)
In article <691@unm-la.UUCP> claborn@unm-la.UUCP (Joe Claborn) writes: >... deleted discussion of what constitutes a "best solution" ... > >The best software to a solve a specific problem may be a piece of 'canned' >software or it may be developed 'in-house'. In either case if there >is not engineering involved in the decision then the solution won't be >'best'. I agree with your criteria. My point was that things which are well-defined are not saved and re-used *in the general case*. All engineering, including the example I used of heat exchanger design, involves original work. It may be that more or fewer parameters or "building blocks" may be available, but sooner or later it comes down to the engineer doing their part. If there was no new engineering to be done, then the customer would (should) have bought an off- the-shelf solution. My point was that not many software building blocks exist, except for relatively trivial functions, which is part of the reason I feel that software engineering today is more art than engineering. In article <635@cresswell.quintus.UUCP> ok@quintus.UUCP (Richard A. O'Keefe) writes: >In article <4618@teddy.UUCP>, svb@teddy.UUCP (Stephen V. Boyle) writes: >> Sure, there are some examples of "canned" routines and algorithms (quicksort >> is what immediately comes to mind) > >Oh dear, I do hope not. Everybody seems to be hypnotised by the NAME >"quicksort". If you check a good reference (Knuth AofP, for example) >you'll find that quicksort is ***not*** a good general-purpose sort! Agreed. The statement was intended to reference a common, relatively well- known case, without making any value judgements about its use or suitability. So, how can software development become more like engineering? Beats me. At this point all I have is vague uncertainties and "sort of - kind of" thoughts about what could be done different. But I think the comparisons with more "traditional" engineering disciplines can display some interesting parallels, along with divergences, regarding engineering practice. -- ... !{decvax,linus,wjh12,mit-eddie,masscomp}!genrad!svb Steve Boyle GenRad Inc, Production Test Division MS 06, 300 Baker Ave, Concord, Mass. 01742
csm@garnet.berkeley.edu (02/10/88)
Do programmers, in general, work under greater time pressure than real engineers? Are there objective metrics by which real engineers have their productivity judged? Is it easier to tell an amateur mechanical engineer from a professional m.e. than it is to tell an amateur C programmer from a professional? - Brad Sherman (Perhaps more importantly, who makes more money and why?)
UH2@PSUVM.BITNET (Lee Sailer) (02/11/88)
In article <4620@teddy.UUCP>, svb@teddy.UUCP (Stephen V. Boyle) says: >So, how can software development become more like engineering? Beats me. At >this point all I have is vague uncertainties and "sort of - kind of" thoughts >about what could be done different. But I think the comparisons with more >"traditional" engineering disciplines can display some interesting parallels, >along with divergences, regarding engineering practice. I have always wondered why there are so few software "handbooks" to go along with all the engineering handbooks. There are lots and lots of little "standard" components in any big program, for example: o sort list in memory with good average time performance o sort external file with good worst case performance o find the first line in a file that satisfies P. o find all lines that satisfy P. o merge two lists. o merge k lists o maintain a priorty queue o parse a regular expression o match a contextr free pattern. etc etc etc. Sure, there are a lot of them, but there are a lot of IC's, too. There are good ways to do all these things, and they could be described in a general way in psuedo-code, or in specific languages, or whatever. They would have to be categorized in some way to make it easy to find the one you need when you need it. Knuth almost satisfies this description, except that it should be called the Handbook of Software Technique, and should be demystified (i.e. use a friendlier notation) so that most programmers could use it. Voila--engineering! 8-) lee
pase@ogcvax.UUCP (Douglas M. Pase) (02/11/88)
In article <hpisod2.16520001> decot@hpisod2.HP.COM (Dave Decot) writes: >I agree that the distinguishing characteristic between what this >"industry" does and engineering is the general unexpectation that what >is produced will perform exactly as specified. ^^ ^^^^^^^^^ There's the rub. If we had a notation sufficiently precise to completely specify what our programs were supposed to do, we would use this specification language as a programming language, write a compiler, and then they would perform exactly as specified. Denotational semantics has been pushed in that direction (if I'm not mistaken). In a sense, the programming language is a specification of the program behavior -- if it doesn't work right, it's because the programmer didn't specify the behaviors correctly. This, by the way, is a favorable argument for using higher-level languages (functional, logic, etc.) when it is possible to do so, and teaching people how to use them without introducing "impurities" into their code. If used correctly, they could boost code reliability, and certainly our understanding of common problems. Code verification for "pure" functional/logic programs is far easier than for imperative languages, to the point of being relatively trivial. Implementations of such languages are becoming efficient to the point of rivaling imperative languages, so efficiency is no longer a problem. They are not yet widely available, nor is there a large programming force that could use them if they were. Maybe that will come later. -- Doug Pase -- ...ucbvax!tektronix!ogcvax!pase or pase@cse.ogc.edu (CSNet)
warren@ihlpf.ATT.COM (Montgomery) (02/11/88)
The question of whether software art or software engineering more correctly describes what software people do is age old. While software development has aspects of both to it, I'd like to suggest that the dominant aspect for any large project is neither, it's management of complexity. In large systems, there are tasks that are clearly engineering. Picking data structures and algorithms to achieve a desired level of fault tolerance is one that comes to mind, as is figuring out how to cope with widely varying loads with acceptible performance. The enterprise that to me most clearly models a software development is that of publishing a large multi-author document, such as a newspaper, a magazine, or an encyclopaedia. There is a large part of the input that is creative in nature, both in determining overall structure and in filling in the sections. There are also many specialized sub-problems, such as page layout, printing, production of figures, obtaining the rights to material taken from other sources, etc. A lousy product will be produced if the basic creative talent of the people who must supply it isn't up to the task. The best printing and layout in the world won't sell a newspaper with poor writers. Assuming that this is taken care of, though, the dominant concern is managing the thousands of individual tasks involved so that they come together when required to make a product. -- Warren Montgomery ihlpf!warren
noise@eneevax.UUCP (Johnson Noise) (02/13/88)
In article <1879@ttidca.TTI.COM> hollombe@ttidcb.tti.com (The Polymath) writes: >In article <6879@agate.BERKELEY.EDU> bks@ALFA.berkeley.edu (Brad Sherman) writes: >>There seems to be a perception among programmers that >>current software development is not really "engineering." >> >>What do "real" engineers do that we do not? > >Engineers typically work with known quantities and predictable results. >What they're doing has usually been done before and is well understood. >(e.g.: We've built a lot of office buildings. We know how long it takes >to put up girders and floors and wiring. There are tables of beam sizes >and riveting codes, etc.). That's why PERT charts work so well with >engineering projects. > I think you are quite wrong. There are many types of buildings that have not been designed or built (e.g. sufficient structure to with- stand natural forces etc.), but what do I know? I'm an electrical clown myself. > >Software designers/builders, on the other hand, are usually doing something >that hasn't been done before. If it had been, why do it again? Why not >just copy it? (It's a bit difficult to copy an office building (-: ). > Uh, no. Think about the algorithms that are commonly used in most programs. I think you will find that most of the ideas were conceived 20-30 years ago. I am not suggesting that new techniques are not discovered or "designed", but think about it. >Software is a more creative, seat-of-the-pants endeavor than "hard" >engineering. There are no tables of beam strengths or fluid flows to >refer to. There are standard references for limited types of algorithms >and these generally are copied rather than built from scratch. But the >reason for any new software project is to make a computer do something it >hasn't done before. There are many unknowns in such an undertaking, which >is why the PERT model doesn't fit software development very well. There's >still some art to it. > I think you should spend a little more time on the other end of your RS-232 cable before making such a statement. I am an electrical engineer, but I have been programming for almost as long. I try to look at both worlds and I think that there not enough poeple with open minds. Philosophy about man-machine interaction is useful, but a machine is still a machine, and man is not. There has been change. In machines it is mostly speed, not concepts. In programs, mostly nomenclature. We are not programmers any more, we software engineers. Fortran, LISP, SNOBOL, Unix, they are all very important milestones, but not of this generation. What more has been accomplished through the change of names? Not nearly as much. We should focus more on what to do, how to do it, and not the labels. Art is subjective, and that can't be changed. A friend of mine is making the final fixes to a 500MW pulsed power modulator. He designed it, built it, and will sign it like any artist would.
daveb@geac.UUCP (David Collier-Brown) (02/14/88)
In article <32637UH2@PSUVM> UH2@PSUVM.BITNET (Lee Sailer) writes: >I have always wondered why there are so few software "handbooks" to go >along with all the engineering handbooks. There are lots and lots >of little "standard" components in any big program, for example: > >o sort list in memory with good average time performance > Well, I've seen about two: Rodgers, David F., "Procedural Elements for Computer Graphics", New York (McGraw-Hill) 1985. ... and I lent my Hopity-and-somebody data structures book out, so I can't give a citation for it. Rare, but not unknown. -- David Collier-Brown. {mnetor yunexus utgpu}!geac!daveb Geac Computers International Inc., | Computer Science loses its 350 Steelcase Road,Markham, Ontario, | memory (if not its mind) CANADA, L3R 1B3 (416) 475-0525 x3279 | every 6 months.
noise@eneevax.UUCP (Johnson Noise) (02/14/88)
In article <3676@ihlpf.ATT.COM> warren@ihlpf.ATT.COM (Montgomery) writes: >The question of whether software art or software engineering more >correctly describes what software people do is age old. While >software development has aspects of both to it, I'd like to suggest >that the dominant aspect for any large project is neither, it's >management of complexity. > I think you hit the <proverb-op1> right on the <proverb-op2>. >In large systems, there are tasks that are clearly engineering. >Picking data structures and algorithms to achieve a desired level of >fault tolerance is one that comes to mind, as is figuring out how to >cope with widely varying loads with acceptible performance. > When people talk about complexity of a project, I give the following example: Unix distribution exec. size: > 30 Mbytes Unix distribution source size: ~ 3 million lines (no comments) Average programmer productivity: < 10 lines/programmer-working day Total project size: ~ 1,200 programmer-years. Clearly a big project. >sources, etc. A lousy product will be produced if the basic >creative talent of the people who must supply it isn't up to the >task. The best printing and layout in the world won't sell a >newspaper with poor writers. Assuming that this is taken care of, >though, the dominant concern is managing the thousands of individual >tasks involved so that they come together when required to make a >product. > I'm glad to find at least one person who thinks clearly about these things.
UH2@PSUVM.BITNET (Lee Sailer) (02/15/88)
In article <1553@ogcvax.UUCP>, pase@ogcvax.UUCP (Douglas M. Pase) says: > >In article <hpisod2.16520001> decot@hpisod2.HP.COM (Dave Decot) writes: >>I agree that the distinguishing characteristic between what this >>"industry" does and engineering is the general unexpectation that what >>is produced will perform exactly as specified. > ^^ ^^^^^^^^^ > >There's the rub. If we had a notation sufficiently precise to completely >specify what our programs were supposed to do, we would use this specification >language as a programming language, write a compiler, and then they would >perform exactly as specified. Denotational semantics has been pushed in that Yes, but... A specification language would specify exactly *what* was to be done, but not necessarily *how*. E.g., "...ans sort the file in less than 5 seconds..." is a specification, but not a compilable program. Of course, languages like Prolog are moving that way... lee
joe@nsc.nsc.com (Joe Caporaletti) (02/20/88)
Virtually every engineering displine of the industrial revolution relies on the analytical concept of functional decomposition. A system is decomposed into processes with well defined input/output effects on other processes. This partitioning is the basic technique for handling complexity by allowing each processes to be understood separately. Software is distinguished from other engineering disciplines by the necessity to specify algorithms as a SEQUENCE of simple one word operations. This is necessary since there is only one central processing unit which can operate on the data in memory. Functional decomposition is used in software as an analytical tool (e.g. data flow diagrams). However, efficient implementation requires sequencing of operations. Therefore, the functionality is transformed to a sequenctial algorithm. There is no simple set of rules for doing this. Although there has been a lot of good research on program proving, there is yet no practical formalism for showing that a particular sequencing of operations is functionally correct. The complexity and unprovable nature of the of the transformation from functionality to sequential algorithmic implementation is unique to software. For example, although a hardware designer has many options for the implementation of some particular combinatorial logic function, the engineer must use standard mathematical techniques (e.g. Boolean Algebra) to prove that the choosen implementation matches the desired functionality. While software walk-throughs are a great idea, they are really a hand-waving substitute for a formal proof. In other engineering disciplines like mechanical or chemical engineering, a great deal of research goes into proving the reliability and repeatability of the basic processes and principles on which they rely. When software can apply the same kind of research to everyday problems, it too will be an engineering discipline. This is probably several years off and will require a sophisticated degree of automated assistance to the process of program transformation. Knuth knew exactly what he was doing when he named his series "The Art of Computer Programming." Joe Caporaletti Software Engineering and Tools Specialist National Semiconductor
terry@wsccs.UUCP (terry) (03/02/88)
In article <4618@teddy.UUCP>, svb@teddy.UUCP (Stephen V. Boyle) writes: > I am aware of algorithm and code libraries, but they are incomplete solutions > to what I am describing. (There is no "Perry's Handbook" for Software > Engineering.) What about Knuth? - terry@wsccs