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.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 109fba,1042f393323e22da X-Google-Attributes: gid109fba,public X-Google-Thread: 1014db,1042f393323e22da X-Google-Attributes: gid1014db,public X-Google-Thread: 103376,1042f393323e22da X-Google-Attributes: gid103376,public From: kaz@vision.crest.nt.com (Kaz Kylheku) Subject: Re: Software Engineering is not a hoax... Date: 1997/05/27 Message-ID: <5mfkfq$297@bcrkh13.bnr.ca>#1/1 X-Deja-AN: 244329085 References: <5mc1a2$icf$1@dbs1.sma.ch> <338B2118.41C67EA6@metaware.com> Organization: Prism Systems Inc. Newsgroups: comp.lang.c++,comp.lang.c,comp.lang.ada Date: 1997-05-27T00:00:00+00:00 List-Id: In article <338B2118.41C67EA6@metaware.com>, Scott Stanchfield wrote: >> I am pretty sure that in 15 years from now, a programmer looking at code will >> immediatly complain if the module is not following the principles of OO or is >> not designed as an Abstract Data Type. > >I'd say this is more akin to "using acceptable grammar" than applying >engineering techniques. I'd say that it's more, because the technique has a definite impact on the verifiablity and maintainability of the program. Abstract data types and OO are more than just mere terms. I would agree with that they aren't _engineering_ techniques. >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! >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. >Car production is basically doing the same thing over and over and over >and over. Things get a bit better and specialized sometimes, but it's >still building something to do the same task. > >I've never written more than one program to do exactly the same task >(unless I'm rewriting it to improve it.) Each time I sit down to code >something the goal is different. This, in turn, implies the combination >of parts needed to construct it, and the order in which those parts are >put together is different. (These "parts" I refer to are language >constructs, known algorithms and simple reusable objects like >containers. Nothing too big, or you're getting into doing the same task >again.) > >Sure, we can use common algorithms and objects such as containers and >math packages. But the overall product is not something that has been >done before, and therefore, there is no proven, repeatable method to >"engineer" that work. 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.