home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / software / 5503 < prev    next >
Encoding:
Text File  |  1993-01-28  |  8.3 KB  |  162 lines

  1. Newsgroups: comp.software-eng
  2. Path: sparky!uunet!charon.amdahl.com!amdahl!rtech!sgiblab!spool.mu.edu!howland.reston.ans.net!paladin.american.edu!news.univie.ac.at!hp4at!mcsun!fuug!kiae!relay1!river!csoft!news-server
  3. From:  smcl@speed.kiev.ua (Scott McLoughlin)
  4. Subject: Re: Why is the Software Process NOT working
  5. Reply-To: smcl@speed.kiev.ua
  6. Organization: Private Scott McLoughlin
  7. Date: Wed, 27 Jan 93 18:51:54 +0200
  8. Message-ID: <AAgshPhOC5@speed.kiev.ua>
  9. Lines: 149
  10. References: <1993Jan26.185901.12145@Veritas.COM>
  11. Sender: news-server@river.cs.kiev.ua
  12.  
  13. Howdy,
  14.  
  15. In his contribution, joshua@Veritas.COM (Joshua Levy) writes
  16.  
  17. >> Graham Perkins argues that the software process is not working for
  18. >> several reasons including:
  19. >> >1) Education not respected
  20. >> >2) Prejudice against academic methods
  21.  
  22. > I think the reason the software process does not work is much simpler.
  23. > Colleges and Universities are expected to teach people the background
  24. > knowledge need to be a good software engineer, and they do not.
  25. > It is that simple.
  26.  
  27. I think that you are building a straw man to knock down.  If we interpret
  28. Graham Perkins as saying that _when_ academia _does_ teach how to build and
  29. manage a software system safely, much of the software development
  30. community does not tune in, I think that he is absolutely correct.
  31.  
  32. The reason is that management would never stomach the costs or the restraints,
  33. prefering instead the illusion of unrestrained creative freedom.  The same
  34. people who realize that they cannot use a design for a home with a basement
  35. when they want to build a house at the beach, the same people who will pay
  36. $55/hour for a plumber to come fix a toilet -- these same people will
  37. say, "Oh, we'll just port our ultra tensor whatcha-magit analysis system
  38. from PrimeOS to Windows 3.X to leverage our clients' current hardware
  39. investment in circa 1988 IBM AT systems.  Let's get the boys in the
  40. basement out for a week of training in Windows programming in C."
  41. What a joke.
  42.  
  43. I'm a youngin', but having worked around the Washington, D.C. beltway for a
  44. few years, I continuously don't know whether to laugh or cry.  It's not
  45. lucrative, but I think I have killed more potential contracts than I
  46. have obtained or executed.  Once the ramifications are explained, users
  47. and managers turn pale and give up.  Good thing too for the taxpayers.
  48.  
  49. You see, inexpensive hardware and software tools (as in, build your own
  50. mailing list with dBase), have cajoled the management and user communities
  51. into thinking that software is forthcoming quicky and on the cheap.  I
  52. think that too much software is being built today.  According to a study
  53. I read some 18 months ago in the NYT, more than 1/2 of the software projects
  54. undertaken in U.S. govt. and Fortune 1000 companies is never used at all.
  55.  
  56. Now, imagine if 1/2 of the factories that we attempted to build were never
  57. used!  This is insanity.  It is management's responsibility to allocate
  58. resources for software development and maintenance.  Any manager who
  59. low balled and therefore failed to successfully develop a couple of
  60. factories would be fired.  Senior management should do this to software
  61. managers who low ball their projects.
  62.  
  63. Software systems are easily as complicated as many factories, and from what
  64. I have read of General Motor's football field size yards to fix cars and
  65. components as they come off of the assembly line, I think that many
  66. software systems that make it into production are easily as high in
  67. quality as many factories. Come on, how many users are asked to help
  68. "clean up" the computer system at the end of their 9 - 5 shift?
  69.  
  70. We, the software development community, are our own worst critics. While
  71. twiddling the ivories might make us feel omnipotent over our machines,
  72. we are only human.  Trust me, I am currently living 90 miles south
  73. of the Chernyobl nuclear reactor.  We should give ourselves a break.
  74.  
  75. >    I never took a class in testing (of any kind).  None was offered.
  76. >    I never took a class in version control or configuration management,
  77. >       or took any class which discussed these issues.   None was offered.
  78. >    One class required writing or helping to write documentation.
  79. >    One class required writing or developing requirements or specifications.
  80. >    I never took a class which discussed the release process.  None was
  81. >       offered.
  82. >    I never took a class which discussed data base systems in any way.
  83. >       None was offered at the undergraduate level.
  84. >    I never took a class which discussed adding features to an already
  85. >       exiting program.  None was offered.
  86. >    I never took a class which discussed porting code or writing portable
  87. >       code.  None was offered.
  88.  
  89. Look, in the absence of a two track educational system, I think that it
  90. is best that university and teaching college attendants learn the ins
  91. and outs of graph theory and compiler optimization, rather than how to
  92. use PVCS or SCCS. As concerns documentation, I was a philosophy student
  93. at Harvard.  I like to write.  But do I want to write user documentation?
  94. Hell no.  Don't waste my time.  Hire some schmuck with a masters degree
  95. in technical writing (better universities do _not_ give undergraduate
  96. degrees in technical writing).
  97.  
  98. Anyway, in my course of study I did _not_ take courses on philosophical
  99. pedagogy or courses on how to write in a dry, philosophy journal style,
  100. quoting all of the tenured staff at my university ;-)  This is
  101. _on the job_ training.  If I were to become a philosophy professor, I
  102. would be given a few years worth of students to practice on.  Similarly,
  103. lawyers are given the underpriveled in "legal clinics" to practice on.
  104. The cost to students in tuition and to the poor in misrepresentation is
  105. !!! $100,000's OF DOLLARS !!! in on the job training for so called
  106. "professionals".  Give a programmer a few $100,000 worth of on the
  107. job training, and I'm sure that even a product of America's university
  108. system can learn PVCS or Oracle.
  109.  
  110. Anyway, this idea that software engineers must be jacks of all trades
  111. is foolish. We are foolish for telling the rest of the world that this
  112. is so.  No one should be surprised if some software engineering guru
  113. who can build a slick device driver or optimized compiler cannot construct
  114. an aesthetically appealing graphical representation of the same
  115. software system.  These are two different skills! Go hire graphic design
  116. types!
  117.  
  118. > How long are schools going to graduate people while pretending that
  119. > testing, version control, release process, data bases, and program
  120. > modifications don't exist?
  121.  
  122. Schools educate _young_ men and women in various disciplines. No one
  123. should be educated in how one's tongue turns gray after the 15th
  124. cup of coffee after arguing all day about what DBMS to procure or
  125. when the bug threshold is "low enough" to release a product to the
  126. public (because the venture capitalists are getting antsy).
  127.  
  128. Furthermore, universities are not job factories.  Given the changing
  129. job market and a rapidly evolving SE field, a job factory would most
  130. likely produce the GM Pacer of programmers.  I would think that even
  131. _more_ attention should be paid to a firm grasp of fundamentals,
  132. especially the ins and outs of system software (graphical subsystems,
  133. memory management, assembler programming, compiler design and operation,
  134. process synchronization issues).  _THESE_ are the issues that do not
  135. change, the perenial issues, in a rapidly changing field.
  136.  
  137. > It is almost funny, in retrospect:  I was forced to take 5 math classes
  138. > and more than 3 science classes, but I was not offered a class which
  139. > required me to write a program which would run on more than one machine,
  140. > and I never had to write a test suite, or modify an already existing
  141. > program.
  142.  
  143. Yes, but your nice U. Penn education probably gave you an excellent
  144. conceptual framework to organize all of the tidbits of SE lore that
  145. you have obviously acquired since then.  Without this framework, it is
  146. all just what I like to call "Tips and Tricks of the DOS <Unix, VMS, etc.>
  147. Masters".  If your subsequent career makes you really want a firmer
  148. grounding in the beurocracy and management that obviously accompanies
  149. institutional and commercail software development, I believe that many
  150. fine MBA programs offer special MIS degrees and that other software
  151. engineering Masters programs (I have a friend who went to George
  152. Mason, for example) pay particular attention to these topics.
  153.  
  154. >  > Joshua Levy  (joshua@veritas.com)
  155.  
  156. Live! From Kiev! Its....
  157.  
  158.         Scott "Be true to your school!" McLoughlin
  159.  
  160.  
  161.  
  162.