home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / lang / c / 16618 < prev    next >
Encoding:
Internet Message Format  |  1992-11-17  |  2.1 KB
  1. Xref: sparky comp.lang.c:16618 comp.software-eng:4325
  2. Newsgroups: comp.lang.c,comp.software-eng
  3. Path: sparky!uunet!ferkel.ucsb.edu!taco!rock!concert!uvaarpa!caen!spool.mu.edu!umn.edu!mmm.serc.3m.com!pwcs!cdsmn!wells
  4. From: wells@cdsmn.mn.org (Rich Wells)
  5. Subject: Re: Will we keep ignoring this productivity issue?
  6. Message-ID: <BxtIF2.45@cdsmn.mn.org>
  7. Organization: Dicomed, Inc
  8. X-Newsreader: TIN [version 1.1 PL6]
  9. References: <1992Nov13.211018.24360@novell.com>
  10. Date: Mon, 16 Nov 1992 16:42:36 GMT
  11. Lines: 34
  12.  
  13. Duane Murphy (damurphy@wc.novell.com) wrote:
  14. : I believe that we are not teaching programmers analysis before design.  
  15. : We teach them syntax and pretend that this is analysis.  Analysis is real 
  16. : and important.  How can you design a program that you cannot read!
  17.  
  18. I wholeheartedly agree.  How can one design when one has never seen
  19. a good design from someone else?
  20.  
  21. Example: in my first real-world job, I was given the task of writing
  22. a display system based (loosely!) on the GKS standard.  Reading that
  23. standard - a generic design for a graphics package - taught me more
  24. about software design than any amount of hacking experience ever could.  
  25. It taught orthogonality, how to separate software into layers,
  26. information hiding, abstraction, and even the rudiments of object-
  27. oriented programming.
  28.  
  29. Likewise, I've learned a lot by reading some of the original Bell
  30. Labs articles about Unix.
  31.  
  32. In short, I think Duane has a good point.  An important and almost
  33. always entirely neglected part of a software engineering education
  34. (by whatever name you give it) is the study, analysis, and criticism
  35. of past designs.  After all, the best way to see where we're going
  36. is to see where we've been.  Software engineers, as a whole, have
  37. little sense of history.
  38.  
  39. BTW: Let's not get into a discussion of GKS here; such discussion would
  40. belong on comp.graphics, and given how outdated GKS is now, probably
  41. wouldn't even be welcome there.  Suffice it to say that GKS was by
  42. no means perfect, but had a well enough written standard that I was
  43. able to learn a lot of valuable lessons from it.
  44. -- 
  45.  
  46. Richard Wells  wells@cdsmn.mn.org  or  ...!tcnet!cdsmn!wells
  47.