home *** CD-ROM | disk | FTP | other *** search
- Newsgroups: comp.software-eng
- Path: sparky!uunet!stanford.edu!leland.Stanford.EDU!fanaraaken.Stanford.EDU!adams
- From: adams@fanaraaken.Stanford.EDU (Allen Adams)
- Subject: Re: What is Software Engineering
- Message-ID: <adams.713631377@fanaraaken.Stanford.EDU>
- Sender: news@leland.Stanford.EDU (Mr News)
- Organization: DSO, Stanford University
- References: <1992Aug3.225335.13213@projtech.com> <1992Aug6.114743@iti.gov.sg> <adams.713466914@fanaraaken.Stanford.EDU> <1992Aug11.230629.6592@ennews.eas.asu.edu>
- Date: 12 Aug 92 14:56:17 GMT
- Lines: 80
-
- kanko@enuxha.eas.asu.edu (Mark Kanko) writes:
-
- >In article <adams.713466914@fanaraaken.Stanford.EDU>, adams@fanaraaken.Stanford.EDU (Allen Adams) writes:
-
- >> As one electrical engineer told me, "My job as an engineer
- >> is to make things work, no matter what." Therefore, my conclusion is
-
- > This EE does dis-service to his profession. Every job has constrints.
- > Does '...no matter what...' include 'working' for only 5 minutes before
- > burning out the power supply? Of course not! Virtually every H/W effort
- > has reliability and maintainability (R&M) constraints somewhere in the
- > spec. Same should hold true for software. (Hoo-boy. I can see the
- > defect density and MTBF discussions coming already... ;-) )
-
- >> is to make things work, no matter what." Therefore, my conclusion is
- >> that 'hacking' is and should be the job of an engineer. To 'engineer'
- >> software, as the latest software engineering principle's tell us, really
- >> is not engineering. Maybe we should call ourselves 'software artists'.
- >
- > Sorry, your conclusion(s) is (are) based on a faulty assumption.
- > [Or was your whole post a tongue-in-cheek?]
-
- The EE example was intended to show why some engineers think it is 'silly'
- to practice the principle's espoused by 'software engineers'. This
- was said during an effort that I was leading where we were converting
- software I had written from Pascal to Ada. The two other main player's
- backgrounds in this situation, besides myself, were EE and CS. The CS
- person had done several things in Ada and was trying to approach the
- conversion in, for lack of better words, an object-oriented manner (this
- was before OOP was the latest buzzword). The EE (as an aside here, I am
- not trying to portray this EE as an example of ALL EEs, just using him
- as a reference point) wanted no part of this. Ada was just another
- language like FORTRAN and he felt that to try and 'software engineer'
- the solution just got in the way of getting his job done on time.
- Since I was interested in other things at the time, I let each person
- go on the paths they felt more comfortable with. The exercise, in my
- mind, proved that you could develop packages in Ada that can and will
- be re-used, as well as a person has the ability to treat Ada like
- FORTRAN and generate code, that might be messy, but 'works' just
- like the 'software engineered' code.
-
- So this leads me to two points. The first is that the 'ilities'
- associated with software engineering are meant to help people
- cope with the problems they have had/still do have/will continue to have
- with modifying code when some 'baseline' is reached. This applies
- to code sizes small, medium, and large. Now there are things in
- software engineering, like object-oriented design, data flow analysis,
- etc., that help people reach the initial baseline they are striving for.
- If done properly, not only will this 'software engineering' help them
- make changes to this baseline, it should also help them, or some poor
- lost soul who has the misfortune of picking up this baseline from
- someone else, figure out what they were doing when they reached this
- baseline. In my example above, the EE ran into problems several times
- because of his design/lack thereof. Was this due to inexperience??
- Maybe, but as time went on, I think he wished he had done some of
- the 'software engineering techniques' that he knew about, but ignored.
-
- My second point deals with my reference to 'software artists', rather
- than 'software engineer'. If you apply the 'software engineering
- techniques', one will find the strengths and weaknesses in doing so.
- But the knowledge base that one will obtain will allow them to
- tackle the next software assignment with more 'colors on their palette.'
- If one only knows about red, green, and blue (do loops, if-then-else,
- assignment statements) a picture can indeed be painted, and 'beauty
- will be in the eye of the beholder.' If one has more colors, a different
- picture can be painted. But I will bet you the person that had the
- red, green, and blue will try and logically explain why there 'picture'
- is better, as will an argument come from the painter with more colors.
- Neither side will listen to the other, and each artist will be
- resistent to the other side. So to conclude, I like 'software
- engineering techniques' because I like trying new ways to solve
- problems, and every time I apply them, I learn something new.
- It is very hard to argue with someone who has painted their picture
- with red, green, and blue, maybe painfully mixed some of the colors to
- get green, yellow, magenta, cyan, black, and white, and they are
- 'proud' of their picture. To tell them otherwise is 'insulting to
- them.'
-
- Allen Adams
-
-