gls@odyssey.att.com (Col. G. L. Sicherman) (01/27/91)
In <10185@as0c.sei.cmu.edu>, rsd@sei.cmu.edu writes: > > There is some confusion here between the roles of engineering and science. > Science is discovery through hypothesis testing (in books, anyway, where > serendipity is ignored); engineering fabricating from the known. Engineers > build what they already know how to build, with only small differences > allowed between successive designs. We would never award a contract to a > engineering firm that has never build a bridge before. > > However, we let programmers hack away at things they've never built before, > on our money, and express surprise at the results. Of course we do! Why should I write the same program twice? Once a program works, everybody can use it; software can be copied. But you can't copy a bridge in shar format. That's why construction workers mostly do old things and we programmers mostly do new things. This is also why managers who treat software as a manufacturing product go wrong. Mass manufacturing deals in repeated products--it rests on Baconian science in its dependence on repeatability. Software lies at the boundary between order and chaos. That's what it's for, so it *always* heads for the boundary. Software makes nonsense of mass markets and other anomalies of print-age culture. (And print-age culture interprets this phenomenon as "transition to a service economy.") In programming, software engineering cannot push back the boundary--it can only modify its geometry. The programmer's greater understanding informs the program much as music informs a collection of notes. When nobody maintains your pencil sharpener, it works fine; when nobody takes *personal* responsibility for a program, it soon rots. And the rot is imponderable to engineers, for they are trained to abstract the problem from the people. -:- "The identical is equal to itself, since it is different." --Franco Spisani, _Philosophical Foundations of Autogenetic Logic_ -- Col. G. L. Sicherman gls@odyssey.att.COM
djbailey@skyler.mavd.honeywell.com (01/29/91)
In article <1991Jan27.234614.2327@cbnewsc.att.com>, kca@cbnewsc.att.com (k.c.archie) writes: > ... One of the ways software development and > engineering differ is that engineers build on existing work. > They don't design I-beams when designing a bridge. > Programmers not only re-design the I-beams, they perform custom metallurgy. No. Custom metallurgy would mean designing a new programming language from scratch and that is rare. There is an interesting analogy in "Wicked Problems, Righteous Solutions" by Peter DeGrace and Leslie Hulet Stahl comparing software developers to the craftsmen who built cathedrals in the Middle Ages. Like the craftsmen, we have a lot of practical techniques and "rules of thumb" to help us build but we don't have the scientific background to understand why it works and how to make it work consistantly. By the way, the book has a well-documented and fair discussion of the Waterfall model of Software Development and how some other popular software development models compare to it. It's a good book. One of the points made in this book and other places is that software development takes place in the mind and the mind is unexplored territory. If we can teach people to become expert problem solvers, then we will have developed the scientific background we need for software development. -- Don J. Bailey
sartin@hplabsz.HP.COM (Rob Sartin) (01/29/91)
In article <1991Jan28.125444.71@skyler.mavd.honeywell.com> djbailey@skyler.mavd.honeywell.com writes: >No. Custom metallurgy would mean designing a new programming language >from scratch and that is rare. Not as rare as one might hope. I've been on and observed a number of projects that used custom programming languages* (usually preprocessors to another language). My observaton is that software folks often get more carried away with the pure technology rather than focusing on solving the problem. Rob
throop@aurs01.UUCP (Wayne Throop) (01/30/91)
> sartin@hplabsz.HP.COM (Rob Sartin) >> djbailey@skyler.mavd.honeywell.com >>No. Custom metallurgy would mean designing a new programming language >>from scratch and that is rare. > Not as rare as one might hope. [...] > My observaton is that software folks often get more carried away with > the pure technology rather than focusing on solving the problem. I'm of the opinion that it isn't as *common* as one might hope. ( Where "it" is the coining of custom languages/notations. ) I'm a great believer in "tiny languages" a-la Bentley, eg: consider the origins of "pic". The productivity improvement of jootsing (a-la Hofstadter) to a semantically "denser" notation can be immense. Mind you, I don't doubt for a minute that this technique can be abused, I just don't think it is *used* in many of the places it "ought" to be. An approximately true story: I remember a conversation between a developer and a manager. The manager well knew the developer's tendency to solve the more general problem and invent "tiny languages". The conversation went something like this: mgr: How long will it take you to [solve problem so-and-so]? dev: Oh... [thoughtful pause]... about six weeks. mgr: That long? Remember, I don't want you to be wasting time solving somebody else's problem or inventing fanciful preprocessors! dev: Ah! [second, slightly longer thoughtful pause]... then, about ten weeks. Wayne Throop ...!mcnc!aurgate!throop
pcg@spl27.spl.loral.com (Paul C George) (01/30/91)
In article <1991Jan28.125444.71@skyler.mavd.honeywell.com>, djbailey@skyler.mavd.honeywell.com writes: |> There is an interesting analogy in "Wicked Problems, Righteous |> Solutions" by Peter DeGrace and Leslie Hulet Stahl comparing software |> developers to the craftsmen who built cathedrals in the Middle Ages. |> |> Like the craftsmen, we have a lot of practical techniques and "rules |> of thumb" to help us build but we don't have the scientific background |> to understand why it works and how to make it work consistantly. |> ...... |> One of the points made in this book and other places is that software |> development takes place in the mind and the mind is unexplored |> territory. If we can teach people to become expert problem solvers, |> then we will have developed the scientific background we need for |> software development. |> |> -- Don J. Bailey At the risk of being flippant, I am reminded of a comment by Sam Redwine at the 1988 Software Process Workshop, which won the best line award: Software and Cathedrals are much the same - First we build them, then we pray. If we ever actually use an engineering process where we specify, design, implement and verify software, perhaps we can get beyond this. Current bidding & scheduling practices make it so we rarely actually design software. Thought is regarded as a non-productive activity, as it is hard to judge the quantity & quality of output. Creating lines of code or numbers of modules (even incorrect or useless ones) are easy to measure and give the illusion of progress. The current software engineering process seems to be: 1) market, 2) take a cursury look at the problem & possible solution (requirements analysis & Design) 3) wave hands & philosophise, smoke & mirrors optional (customer requirements & design reviews), 4) implement as as the spirit moves based upon individual understanding, 5) find out what you built ('integration testing'), 6) fix until it works, 7) determine functionality (FQT), 8) modify reqirements to reflect the product and/or repeat step 6.
cl@lgc.com (Cameron Laird) (01/30/91)
In article <59483@aurs01.UUCP> throop@aurs01.UUCP (Wayne Throop) writes: . . . >> My observaton is that software folks often get more carried away with >> the pure technology rather than focusing on solving the problem. > >I'm of the opinion that it isn't as *common* as one might hope. >( Where "it" is the coining of custom languages/notations. ) > >I'm a great believer in "tiny languages" a-la Bentley, eg: consider the >origins of "pic". The productivity improvement of jootsing (a-la >Hofstadter) to a semantically "denser" notation can be immense. . . . Seconded. I'm not well-enough read to know that Bentley and Hof- stadter had labels for these notions, but I recognize quite well what you're saying. Constraints can enable, I claim; the disci- pline of defining a "tiny language" generally promotes quicker understanding of what the salient design issues are. -- Cameron Laird USA 713-579-4613 cl@lgc.com USA 713-996-8546
chip@tct.uucp (Chip Salzenberg) (01/30/91)
According to sartin@cup.hp.com (Rob Sartin): >I've been on and observed a number of projects that used custom >programming languages* (usually preprocessors to another language). I see nothing wrong with using custom languages as one tool in solving programming problems. Besides, "custom metallurgy" would be a brand new language from scratch, not a minor preprocessor hack. -- Chip Salzenberg at Teltronics/TCT <chip@tct.uucp>, <uunet!pdn!tct!chip> "I want to mention that my opinions whether real or not are MY opinions." -- the inevitable William "Billy" Steinmetz