home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / programm / 2387 < prev    next >
Encoding:
Internet Message Format  |  1992-08-19  |  2.8 KB
  1. Path: sparky!uunet!ogicse!das-news.harvard.edu!husc-news.harvard.edu!peregrin
  2. From: peregrin@husc13.harvard.edu
  3. Newsgroups: comp.programming
  4. Subject: Teaching by Value (was Re: Teaching the Basics)
  5. Message-ID: <1992Aug19.142513.14893@husc13.harvard.edu>
  6. Date: 19 Aug 92 18:25:13 GMT
  7. Article-I.D.: husc13.1992Aug19.142513.14893
  8. References: <1992Aug17.123916.14815@husc13.harvard.edu> <Bt6DGq.HuB@metropolis.com> <1992Aug18.190506.9935@cc.gatech.edu> <1992Aug18.230426.26425@lucid.com> <1992Aug19.135744.14889@husc13.harvard.edu>
  9. Organization: Harvard Business School
  10. Lines: 59
  11.  
  12. Okay, to continue with this thread I started ...
  13.  
  14.     We currently grade our introductory programming course thusly:
  15.  
  16.         60% - getting the answer right
  17.         20% - style (documentation, indentation, etc.)
  18.         20% - design (input checking, efficiency, etc.)
  19.  
  20.     The reason for the 60% chunk is that it is easier to give partial
  21. credit for incomplete programs.
  22.  
  23.     But should we stress the grading differently?  In the real world,
  24. is the value of a program more like:
  25.  
  26.         40% - Meets specs.
  27.         40% - Robust (doesn't crash or crashes cleanly)
  28.         20% - Maintainability
  29.  
  30.     or maybe like this:
  31.  
  32.         5% - Maintainability
  33.         70%- Meets specs
  34.         25%- Robust
  35.  
  36. especially since in today's market, you have to get the damn program out
  37. the door as quick as you can.  Maintainability considerations are rarely
  38. thought about except for the individual programmer's concern that he/she
  39. can debug their own code?  Does anyone slow down to make their code
  40. more maintainable?
  41.  
  42.     If we wanted to teach programmers what it is really like in the
  43. real world, should we way things like this:
  44.  
  45.  
  46.     70% - meets specs
  47.     30% - robust (can't be crashed)
  48.  
  49.     -20% per day past due date
  50.  
  51.  
  52.     Should efficiency really be a concern at the introductory
  53. level? Should that concern be reduced so that more time can be spent on
  54. problem solving?
  55.  
  56.     If you look at your programming peers, are you more concerned that
  57. they can write easily maintainable code than if they can write super-slick
  58. fast routines?  Who do you want on your programming team?  Should the
  59. majority of programmers be writers of clean, easy to read and maintain
  60. code, and only a few are needed to right tight, fast, efficient routines?
  61.  
  62. -James
  63. +----------------------------------------------------------------------------+
  64. | James Peregrino                        |       peregrin@hbsstg.harvard.edu |
  65. | Programmer/Analyst                     |       PEREGRIN@HULAW1.BITNET      | 
  66. | Science & Technology Interest Group    +-----------------------------------+
  67. | Harvard Business School                | "Renovations Underway,            |
  68. | Boston, MA 02163                       |  Thank You for Your Patience.     |
  69. | Voice:(617)495-6307 FAX:(617)495-0351  |  Will Reopen Soon."               |
  70. +----------------------------------------------------------------------------+
  71.