From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,1042f393323e22da X-Google-Attributes: gid103376,public X-Google-Thread: 1014db,1042f393323e22da X-Google-Attributes: gid1014db,public X-Google-Thread: 109fba,1042f393323e22da X-Google-Attributes: gid109fba,public From: Scott Stanchfield Subject: Re: Software Engineering is not a hoax... Date: 1997/05/27 Message-ID: <338B81EA.167EB0E7@metaware.com> X-Deja-AN: 244367434 References: <5mc1a2$icf$1@dbs1.sma.ch> <338B2118.41C67EA6@metaware.com> <5mfkfq$297@bcrkh13.bnr.ca> Organization: MetaWare Incorporated Newsgroups: comp.lang.c++,comp.lang.c,comp.lang.ada Date: 1997-05-27T00:00:00+00:00 List-Id: Kaz Kylheku wrote: > > In article <338B2118.41C67EA6@metaware.com>, > Scott Stanchfield wrote: > > > >Think about "Ugh! Me Kronk" versus "Hello, my name is Scott." Did I > >engineer that sentence? I applied grammatical rules, but I wouldn't say > >that it was engineered. > > I see what you are getting at. Since a program is an utterance in a programming > language, it's not a product of engineering but of abstract symbol > manipulation. Good point! Thank you! > > >The problem I have with the notion of Software "Engineering" is when > >people say software development is just like building cars. > >That's just a plain bad analogy. Think about car production. Cars do > >one thing -- transport. Sure, some can be more fun than others, some > >may be better at towing, some may carry more people, but they are all > >basically the same. The parts used to make them are basically the same. > > But we can have reusable components. Different models of car are similar in the > same kinds of ways as two different red-black tree implementations. Their > parts are not interchangeable, yet they are basically the same. > > I would not go as far as saying that there are no useful similarities between > engineering and software development, or that some of the rigorous techniques > in engineering can be applied to software, in particular, the technique of > formal verification. In engineering, designs are verified. For example, a truss > will undergo analysis in which the tensile or compressive stresses in each > member are determined under given load conditions. Nobody will build the bridge > without having done such an analysis. To apply this principle of verification > to software, every component of a software project should be formally verified > for correctness. Guess my point got missed here. In cars, common parts are assembled in pretty much the same manner for any given car. Testing a car is similar from car to car. Same domain for each "overall" test. (Car testers -- please do not be offended -- I'm not saying your job is simple...) (How did we move into testing?) In programming, each new program presents a different domain. In order to test, you have to think in that domain and create new tests within it. Sure, there are similarities, but no "checklist" that says what things to think of when testing a car. (I also believe it has been proven that program correctness is, in general, unprovable. There are simple subsets that can be proven correct, but as program size grows, the probability of proving correctness diminishes.) [snip re I don't write the same thing twice] > > Then again, many engineering designs are also unique. Think of unique > structures in the world: dams, buildings, bridges and so on. There are proven, > repeatable ways to locally verify the designs, one component at a time. > E.g. there are methods to analyze any truss network to see whether it will > hold up, but you can still be very creative in designing the truss. > In engineering, the creativity is checked by applying laws derived > from natural science. gears having buddha nature :) > Again, unsure how we got into testing, but... >From what I recall of my Naval-Architect roomie's ramblings on structural analysis, I think it's somehow related to physics ;) Science vs. art, and ya know where I stand... Anyway, certain parts of programs can be tested with common program testing techniques, just as certain parts of programs implement common algorithms and data structures. But, I think that developing the proper test for a propgram is just as unique as writing the program to begin with. It's a matter of figuring out the right combinations of common tests and new tests to get the "warm fuzzies" or, better still, complete confidence in the correct operation of a program. (In that respect, verification of design of some structures is a creative process as well.) Think about geometric theorem proving. You have a set of "knowns" and an "unknown." You have to think out the correct combination of "knowns" to prove your unknown. No engineering technique can tell you how to combine them, though you can learn useful patters that can help get the job done. (This is the most intellgent discussion of this topic that I've heard in a while -- very interesting...) -- Scott -- Scott Stanchfield MetaWare Incorporated Santa Cruz, CA (The opinions expressed herein are not necessarily those of MetaWare)