home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / lang / fortran / 3219 < prev    next >
Encoding:
Text File  |  1992-08-27  |  4.8 KB  |  98 lines

  1. Newsgroups: comp.lang.fortran
  2. Path: sparky!uunet!boulder!khonshu!ejh
  3. From: ejh@khonshu.colorado.edu (Edward J. Hartnett)
  4. Subject: Re: scientists as programmers
  5. Message-ID: <1992Aug27.140153.23191@colorado.edu>
  6. Sender: news@colorado.edu (The Daily Planet)
  7. Nntp-Posting-Host: khonshu.colorado.edu
  8. Organization: Cooperative Institute for Research in the Environmental Sciences
  9. Date: Thu, 27 Aug 1992 14:01:53 GMT
  10. Lines: 86
  11.  
  12. In-reply-to: schuette@wl.com's message of Wed, 26 Aug 1992 10:27:35 GMT
  13. Newsgroups: comp.edu,comp.lang.fortran
  14. Subject: Re: scientists as programmers (was: Small Language Wanted)
  15. References: <1992Aug25.034553.2990@linus.mitre.org> <1992Aug25.154501.8654@colorado.edu>
  16.     <1992Aug25.202307.12365@newshost.lanl.gov>
  17.     <1992Aug26.102735.12519@wl.com>
  18. Distribution: 
  19. FCC: /home/khonshu/ejh/News/outgoing
  20.  
  21. --text follows this line-- 
  22.  
  23. In article <1992Aug26.102735.12519@wl.com> schuette@wl.com (Wade Schuette) writes:
  24.  
  25.    OK, so having gone back and forth, maybe we have a sense now that there
  26.    are scientists who write good code and scientists who don't, perhaps in
  27.    a different ratio than people who spend more time focusing on programming
  28.    issues. 
  29.  
  30.    Can we focus some attention on what CAN and SHOULD be taught to the
  31.    scientists who would prefer to write good code and are reasonably bright
  32.    but extremely busy.  On a very practical, very pragmatic basis.
  33.    Suppose you can get 45 minutes of time, and hold a seminar on What every
  34.    scientist should know about computing but probably doesnn't... or some such.
  35.  
  36.    One shot.  The room is impatient. The top people are late. (the projector
  37.    doesn't focus.) Now what?  This is a serious question, as I'd like to do
  38.    precisely this, for an audience of primarily biological / chemical 
  39.    researchers.  Software Engineering 101, extremely applied, for people
  40.    heavily into Fortran and "getting results today."
  41.  
  42.    Or maybe, this: if you had ONE thing you could try to get across, that would
  43.    make sense to that audience in that time frame, what would it be?
  44.    ==================================================================
  45.    R. Wade Schuette         schuette@wl.com    Ann Arbor, MI, USA
  46.  
  47.  
  48. I think I should have been more clear when I said that scientists are,
  49. in general, not as good programmers as professionals. I also make a
  50. distinction between coding and programming, which is this: good code
  51. is compact and efficient, but a good program is good code that is well
  52. organized, and, most importantly, well documented.
  53.  
  54. If I could sit down all those scientists in a room and tell them one
  55. thing, it would be that in all my experience programming, nothing is
  56. more worthwhile than documentation. Particularly with science, if it's
  57. not documented, it's almost useless, and will be completely useless
  58. whenever it's handed to someone other than the original programmer.
  59. Why? Because with science you have to KNOW what's going on in the
  60. code. A small mistake can EASILY skew scientific results. And the time
  61. invested in organization and documentation is more than repaid again
  62. and again. 
  63.  
  64. However, I don't think they'll listen. Why, I don't know, but it seems
  65. impossible to convince a lot of them, unless they already have been
  66. burned by having huge amounts of code turn useless at the departure of
  67. a programmer. Then they might think "I don't want this to happen
  68. again." However, with their own code, they will not get burned
  69. like this, they will burn someone else maybe, but they won't be around
  70. to witness that. And without that kind of experience, it's hard to
  71. convince them that even working with their own code would be a lot
  72. easier if it were better documented and organized.
  73.  
  74. I guess it's exactly the same with professional programmers; I wasn't
  75. convinced of this until I ended up with a job working on someone
  76. else's code, (in fact it's happened to me many times), and I almost
  77. cry to see that so much of their work is wasted, and has to be redone,
  78. when just a few hours a week would have made it permanently useful - a
  79. springboard for their successors, instead of a millstone around their
  80. necks. That's why I started being such a fanatic for documentation.
  81. And it was only after that that I realized it was helping me a lot
  82. too. I think few scientists go through this process, because they most
  83. often start and work on their own projects - they don't often take up
  84. where someone else left off, in the middle of the programs.
  85.  
  86. I certainly didn't mean to make such a blanket statement as
  87. "scientists are bad programmers." What I should have said is that it's
  88. unfortunate that so few scientists (in my experience) realize the
  89. importantance of comprehensive documentation and well organized code.
  90. C.S. and C.E. people tend to have this drummed into them more in their
  91. training. (Scientists think "why?" Engineers think "how?").
  92.  
  93. Sorry about the length of the post!
  94.  
  95. -- 
  96. Edward Hartnett            ejh@khonshu.colorado.edu
  97.  
  98.