home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / lang / c / 16454 < prev    next >
Encoding:
Internet Message Format  |  1992-11-13  |  4.3 KB
  1. Xref: sparky comp.lang.c:16454 comp.software-eng:4264
  2. Path: sparky!uunet!dtix!darwin.sura.net!wupost!cs.uiuc.edu!johnson
  3. From: johnson@cs.uiuc.edu (Ralph Johnson)
  4. Newsgroups: comp.lang.c,comp.software-eng
  5. Subject: Re: Will we keep ignoring this productivity issue?
  6. Message-ID: <BxnpJL.BvM@cs.uiuc.edu>
  7. Date: 13 Nov 92 13:30:56 GMT
  8. References: <Bwtn3H.F2@iat.holonet.net> <1992Nov1.132750.9856@vax.oxford.ac.uk> <1992Nov11.055130@eklektix.com> <1992Nov13.062945.425@thunder.mcrcim.mcgill.edu>
  9. Organization: University of Illinois, Dept. of Comp. Sci., Urbana, IL
  10. Lines: 75
  11.  
  12. mouse@thunder.mcrcim.mcgill.edu (der Mouse) writes:
  13.  
  14. >But from what I can tell, high-level hacking is
  15. >not something that can be put into words, never mind analyzed
  16. >reductionistically.
  17.  
  18. I disagree.  I think that if we study how people *actually* do things,
  19. instead of just making up a theory of how they should do things, we
  20. can learn a lot about how to teach people to do better.  One problem
  21. is that computer scientists don't know how to study people; that is
  22. the job of psychologists.
  23.  
  24. People have studied how good programmers work, and what they have
  25. found indicates (to me, at least) that the way we teach people design
  26. is faulty.  We usually teach people design by teaching them a design
  27. method that consists of a set of notations, usually graphical, and a
  28. set of rules that tell how and when to use each notation, how to link
  29. notations, problems that occur in a design and how to fix them, and
  30. how to evaluate designs expressed in these notations.  But good
  31. designers also depend on a large body of more domain specific
  32. knowledge about design, including algorithms, data structures, and
  33. design idioms.  This domain specific knowledge is just as important as
  34. the notations for recording design and the rules for using those notations.
  35.  
  36. Studies of expert programmers have shown that knowledge is not
  37. organized around syntax, but in larger conceptual structures, such as
  38. algorithms and data structures [Adelson and Soloway].  Soloway
  39. claims that expert programmers organize their knowledge in plans
  40. that indicate the steps necessary to fulfill a particular goal
  41. [Soloway and Ehrlich].   In the same way, it is likely that good
  42. designers do not think about the notation they are using for 
  43. recording the design as much as they are looking for patterns that
  44. they can match against design plans that they have learned in the
  45. past.  Recognizing and teaching these design plans is therefore
  46. necessary to produce good designers, but we don't do it.
  47.  
  48. Simply teaching design notations and rules for using them is unlikely
  49. to be more effective at producing good designers than teaching
  50. language syntax and rules for using it is at producing good
  51. programmers.  The best way to teach programming is to explicitly teach
  52. plans and to explain how they are combined with each other to form
  53. complete programs [Linn and Clancy].  That is probably the best way to
  54. teach design, too.  However, this requires having a set of plans to teach.
  55.  
  56. What I think computer scientists should be doing is enumerating the
  57. design plans that good programmers actually use.  We should enumerate
  58. debugging strategies, rules of thumb for solving design problems, etc.
  59. This is much more important in the long run than the current
  60. preoccupation with using pretty pictures for design notation.
  61.  
  62. Here are some good papers to read that back up what I am saying.
  63.  
  64. Adelson, B. and Elliot Soloway.  The Role of Domain Experience in
  65. Software Design.  IEEE Trans. on Software Engineering, V. SE-11, N 11,
  66. 1985, pp. 1351-1360.
  67.  
  68. Curtis, Bill.  Cognitive Issues in Reusing Software Artifacts.  In
  69. Software Reusability, V. II  ed. Ted J. Biggerstaff and Alan J.
  70. Perlis, Addison-Wesley 1989, pp. 269-287.
  71.  
  72. Linn, Marcia C. and Michael J. Clancy.  The Case for Case Studies of
  73. Programming Problems.  Communications of the ACM  V. 35, N 3, March
  74. 1992, pp. 121-132.
  75.  
  76. Rich, Charles and Richard C. Waters.  Formalizing Reusable Software
  77. Components in the Programmer's Apprentice.   In Software Reusability,
  78. V. II  ed. Ted J. Biggerstaff and Alan J. Perlis, Addison-Wesley 1989,
  79. pp. 313-343.
  80.  
  81. Soloway, Elliot and Kate Ehrlich.  Empirical Studies of Programming
  82. Knowledge, IEEE Transactions on SOftware Engineering V SE-10, N5,
  83. September 1984.  Reprinted in Software Reusability V II.
  84.  
  85.  
  86. Ralph Johnson -- University of Illinois at Urbana-Champaign
  87.