home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / org / eff / talk / 8321 < prev    next >
Encoding:
Text File  |  1993-01-05  |  4.2 KB  |  83 lines

  1. Newsgroups: comp.org.eff.talk
  2. Path: sparky!uunet!zaphod.mps.ohio-state.edu!magnus.acs.ohio-state.edu!usenet.ins.cwru.edu!gatech!emory!nastar!phardie
  3. From: phardie@nastar.uucp (Pete Hardie)
  4. Subject: Re: Software as PE
  5. Message-ID: <1993Jan5.154910.19144@nastar.uucp>
  6. Organization: Digital Transmission Systems, Duluth, GA.
  7. References: <889520164DN5.61R@tanda.isis.org> <1992Dec30.125324.27900@mksol.dseg.ti.com> <522322457DN5.61R@tanda.isis.org>
  8. Distribution: na
  9. Date: Tue, 5 Jan 1993 15:49:10 GMT
  10. Lines: 71
  11.  
  12. In article <522322457DN5.61R@tanda.isis.org> marc@tanda.isis.org writes:
  13. >        Not part of the definition but worth noting: When I buy
  14. >        something engineered, it comes with a warranty; When I buy
  15. >        software, it comes with a disclaimer.
  16.  
  17. A comment:  Most warranties I read attempt to disclaim all faults except
  18. material failure.  They do not state that the product will perform in the
  19. desired manner, they guarantee a replacement if it fails to perform.
  20.  
  21. >        It was a software engineer who decided that the brakes on the
  22. >        Fokker 100 shouldn't operate if a sensor indicated the wheels
  23. >        were up. They were designated part of the "on the ground"
  24. >        module. An aircraft systems engineer would have understood the
  25. >        difference between the sensor and the fact, recognised that
  26. >        applying brakes in midair could do no harm, and saved a few
  27. >        pilots a change of underwear.
  28.  
  29. First of all, is this a confirmed thing?
  30.  
  31. Secondly, just to clarify:  is the problem here that a sensor failed, thus
  32. preventing the brakes from operating when the wheels were in fact down?
  33.  
  34. Thirdly, you are making a general statement about software people based on
  35. a single decision by one.  Another software engineer might have seen that
  36. applying the brakes with the gear up was non-harmful and allowed it.  Certainly
  37. the review of the functionality should have pointed this out.  This is not
  38. a condemnation of software engineers, but rather of narrow-mindedness in design,
  39. not too far removed from the Ford Pinto fuel tank fiasco.
  40.  
  41. >        No electronic engineer has ever advertised himself as expert
  42. >        only with the "Apex Model 5 Logic Analyser". Anyone who
  43. >        studied to be an electrical engineer with me can, in
  44. >        addition to engineering electrical systems, design a logic
  45. >        circuit or machine tool, program any computer, build a barn or
  46. >        a cannon, distinguish between a terminal moraine and a
  47. >        land-fill site, survey a meadow, and navigate a ship.
  48.  
  49. Similarly, any 'Computer Science Engineer' who studied with me can build a
  50. logic circuit, program a computer, plot ballistic trajectories, design a
  51. bridge or scaffold-tower, budget a hydro-electric project, write a magazine
  52. article, balance a ohydation-reduction reaction, or anneal a metal blade.
  53. Breadth in education is not prohibited to a CS major, y'know, nor is it a
  54. discouraged thing.
  55.  
  56. I'll agree that software development is certainly a long way from the 
  57. disciplines of civil and mechanical engineering, or even the newcomer of
  58. electrical engineering.  And perhaps it is a bit premature for us to be using
  59. 'engineering' as a descriptive term.  But we *are* getting there, and we
  60. *are* using the best methods to make software into a reliable feature.
  61.  
  62. >        You'll know the time has come when recruitment ads for
  63. >        programmers (or whatever) don't list programming languages and
  64. >        operating systems, but end-use domain expertise instead. You
  65. >        know there's still a long way to go when most ads for software
  66. >        development _managers_ carry these lists. (You also know that
  67. >        you probably don't want the job.)
  68.  
  69. Interestingly, I have yet to enter a job with more than a minimal end-use
  70. domain knowledge of the product, yet none of the jobs' I've had have ever 
  71. failed because of a lack of that knowledge.  I get the info from those with
  72. the domain expertise, and apply *my* expertise to program it best.  I've seen
  73. some truly horrid software produced by people with excellent end-use domain
  74. knowledge, but little software knowledge - and it shows.
  75.  
  76.  
  77.  
  78. -- 
  79. Pete Hardie:  phardie@nastar  (voice) (404) 497-0101
  80. Digital Transmission Systems, Inc., Duluth GA
  81. Member, DTS Dart Team           |  cat * | egrep -v "signature virus|infection" 
  82. Position:  Goalie               |
  83.