home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / software / 3179 < prev    next >
Encoding:
Text File  |  1992-08-12  |  5.2 KB  |  92 lines

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