home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / lang / c / 16488 < prev    next >
Encoding:
Internet Message Format  |  1992-11-14  |  2.7 KB
  1. Xref: sparky comp.lang.c:16488 comp.software-eng:4278
  2. Newsgroups: comp.lang.c,comp.software-eng
  3. Path: sparky!uunet!ukma!rsg1.er.usgs.gov!darwin.sura.net!sgiblab!newsun!news
  4. From: Duane Murphy <damurphy@wc.novell.com>
  5. Subject: Re: Will we keep ignoring this productivity issue?
  6. Message-ID: <1992Nov13.211018.24360@novell.com>
  7. X-Xxdate: Fri, 13 Nov 92 21:14:20 GMT
  8. Sender: news@novell.com (The Netnews Manager)
  9. Nntp-Posting-Host: 130.57.72.123
  10. Organization: Novell, Inc.
  11. X-Useragent: Nuntius v1.1.1d12
  12. References: <1992Nov11.055130@eklektix.com>
  13. Date: Fri, 13 Nov 1992 21:10:18 GMT
  14. Lines: 44
  15.  
  16. In article Ralph Johnson writes:
  17. >People have studied how good programmers work, and what they have
  18. >found indicates (to me, at least) that the way we teach people design
  19. >is faulty.  We usually teach people design by teaching them a design
  20. >method that consists of a set of notations, usually graphical, and a
  21. >set of rules that tell how and when to use each notation, how to link
  22. >notations, problems that occur in a design and how to fix them, and
  23. >how to evaluate designs expressed in these notations.  But good
  24. >designers also depend on a large body of more domain specific
  25. >knowledge about design, including algorithms, data structures, and
  26. >design idioms.  This domain specific knowledge is just as important as
  27. >the notations for recording design and the rules for using those
  28. notations.
  29.  
  30. ... Even more (good) stuff deleted.
  31.  
  32. I have not been following this discussion very long, but you have brought 
  33. up a point that I have been noticing for a while.  My background is 
  34. originally in Electronic Engineering (that's right the hardware that all 
  35. of you use on a daily basis).  My interest in hardware was only slightly 
  36. more powerful than my interest in software.  So I actually did a little 
  37. (a lot) of both.  
  38.  
  39. Throughout my experience I have repeatedly noticed parallels between the 
  40. two areas.  This is not unusual, they are both engineering problem 
  41. solving based studies.  However, I seem to draw more from my training in 
  42. hardware as I write software.  Hardware design is much older than 
  43. software design (and to a limited extent easier), but the way it is 
  44. taught is far more structured than software.
  45.  
  46. I recall my first software class.  Here is Fortran syntax; write a
  47. program.
  48. Not much training.  Not much experience. Compare that to the first _TWO_
  49. years of hardware.
  50.  
  51. Here is a circuit.  How does it work.  There is _TWO_ years of this.  No 
  52. design, just analysis.
  53.  
  54. I believe that we are not teaching programmers analysis before design.  
  55. We teach them syntax and pretend that this is analysis.  Analysis is real 
  56. and important.  How can you design a program that you cannot read!
  57.  
  58. Just one man's humble opinion,
  59. Duane
  60.