home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / lang / c / 16608 < prev    next >
Encoding:
Internet Message Format  |  1992-11-16  |  2.3 KB
  1. Xref: sparky comp.lang.c:16608 comp.software-eng:4320
  2. Path: sparky!uunet!hela.iti.org!cs.widener.edu!icf.hrb.com!tpd
  3. From: tpd@icf.hrb.com (THOMAS P. DONNELLY)
  4. Newsgroups: comp.lang.c,comp.software-eng
  5. Subject: Re: Will we keep ignoring this productivity issue?
  6. Message-ID: <1992Nov16.130546.19768@icf.hrb.com>
  7. Date: 16 Nov 92 13:05:46 EST
  8. References: <1992Nov11.055130@eklektix.com> <1992Nov13.211018.24360@novell.com>
  9. Organization: HRB Systems, Inc.
  10. Lines: 41
  11.  
  12. In article <1992Nov13.211018.24360@novell.com>, Duane Murphy <damurphy@wc.novell.com> writes:
  13. > In article Ralph Johnson writes:
  14.  
  15.    ... stuff deleted ...
  16. > 
  17. > Throughout my experience I have repeatedly noticed parallels between the 
  18. > two areas.  This is not unusual, they are both engineering problem 
  19. > solving based studies.  However, I seem to draw more from my training in 
  20. > hardware as I write software.  Hardware design is much older than 
  21. > software design (and to a limited extent easier), but the way it is 
  22. > taught is far more structured than software.
  23. > 
  24. > I recall my first software class.  Here is Fortran syntax; write a
  25. > program.
  26. > Not much training.  Not much experience. Compare that to the first _TWO_
  27. > years of hardware.
  28.  
  29. I got my degrees 15 years ago, and it was better than that then.  We even
  30. had courses concerned with top-down structured design, large-scale, 
  31. team-based development, and so on.
  32.  
  33. As for the rest: Hear, hear!  I have a foot in both camps, too, with 
  34. similar (non-commercial) experiences.  Hardware is easier because we 
  35. have made it that way.  It is built much more with levels of implementa-
  36. tion, the levels are better separated, and designs are more modular 
  37. within any one level.  Most of the time.  e.g. chip design is completely
  38. independent of the design that uses the chips.  Boards, likewise, so long
  39. as each level conforms to its interface specifications.
  40.  
  41.  
  42. > I believe that we are not teaching programmers analysis before design.  
  43. > We teach them syntax and pretend that this is analysis.  Analysis is real 
  44. > and important.  How can you design a program that you cannot read!
  45. > 
  46. > Just one man's humble opinion,
  47. > Duane
  48.  
  49. True, as far as it goes.  We need to do a better job of teaching design.
  50. However, I'm unsure that teaching design analysis is a useful precursor
  51. to teaching design.  Perhaps I do not understand what you mean by
  52. analysis.
  53.