home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / bit / listserv / statl / 2222 < prev    next >
Encoding:
Text File  |  1992-12-14  |  3.3 KB  |  62 lines
  1. Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
  2. Path: sparky!uunet!paladin.american.edu!auvm!SUVM.BITNET!SASMAINT
  3. Message-ID: <STAT-L%92121411534868@VM1.MCGILL.CA>
  4. Newsgroups: bit.listserv.stat-l
  5. Date:         Mon, 14 Dec 1992 11:05:19 EST
  6. Sender:       STATISTICAL CONSULTING <STAT-L@MCGILL1.BITNET>
  7. From:         "Nelson R. Pardee" <SASMAINT@SUVM.BITNET>
  8. Subject:      SAS vs SPSS
  9. Lines: 51
  10.  
  11. One of the areas barely touched in the previous discussion is
  12. support. A battle I currently fight is the proliferation of STAT
  13. packages on campus, and not because I think that any one package does
  14. everything. When someone needs help, they come to our Computing
  15. Services organization.  Simple arithmetic comparing the number of
  16. user support personnel to the number of packages we are expected to
  17. support says that we can support one package semi-well.
  18. Some faculty members endeavor to learn and know
  19. what they teach and hence can help their students.  Sadly, many do
  20. not (and students come to us first, regardless of what they are
  21. told). There is need for some students (depending on interest/
  22. discipline/ advancement in learning) to learn a variety of packages.
  23. However, it's generally not productive for folks to struggle with
  24. unfamiliar software without being able to get good help.
  25.  
  26. Another factor is that software costs are becomeing increasingly
  27. problematic. In particular, since it is constantly updated, it
  28. becomes a fixed cost in one's budget.  SAS gets rapped because
  29. everything they sell (except JMP) requires a yearly fee for new
  30. releases, support, etc.  But you get hit anyway with "one time
  31. purchase" software; when the new version comes out, the resulting
  32. clamor for it forces you to buy the next upgrade.  We're getting
  33. eaten alive with this; and every piece of software added makes it
  34. worse. It's like the family budget; the fixed expenses eat up all of
  35. one's income.
  36.  
  37. Finally, I'd like to put in my two cents for "accurate" packages.  I
  38. keep hearing things (here and on the net) about a "nice" package with
  39. "wonderful" graphics and a "friendly" interface.  Folks, these aren't
  40. cars, where the selection criteria is relatively straightforward.  We
  41. wouldn't buy a car no matter the style and ergonomics unless it
  42. "drives" and we expect it to be reliable.  Unfortunately, with a
  43. stats package we must take a great deal on faith about what goes on
  44. inside. Reliability is not usually about obviously failing; it's
  45. about correct answers.  So what if the graphs are pretty?  if the
  46. numbers seem nice.  Are they correct?  Can you tell?  Sometimes.  Ask
  47. somebody (yourself) the next time you choose/use your stats package:
  48. did you check its accuracy (or check with someone reliable who did)?
  49. Writing software is an enormously difficult task.  Don't trust just
  50. anyone to do it right.
  51.  
  52. The next time you want to add another Stat package, ask:
  53.  -can I verify it gives correct answers?
  54.  -will it be supported (there are costs if you support it yourself)
  55.  -can we afford it
  56.  -do I really need it
  57. There are reasons to proceed even if the answer is "no" to all the
  58. above; but at least, you'll have a better idea what you're getting into.
  59.  --Nelson R. Pardee,  Computing Services, Syracuse University          --
  60.  --120 Hinds Hall, Syracuse, NY 13244-1190 USA   (315)443-1079         --
  61.  --Bitnet: SASMAINT@SUVM     Internet: SASMAINT@SUVM.ACS.SYR.EDU       --
  62.