home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / software / 4378 < prev    next >
Encoding:
Text File  |  1992-11-18  |  4.5 KB  |  85 lines
  1. Newsgroups: comp.software-eng
  2. Path: sparky!uunet!gator!miles!rms
  3. From: rms@miles.com (Rob Schultz)
  4. Subject: Enough statistics, what do we do?
  5. Message-ID: <1992Nov18.215032.16720@miles.com>
  6. Organization: Miles Inc., Diagnostics Division, Elkhart, IN
  7. Date: Wed, 18 Nov 1992 21:50:32 GMT
  8. Lines: 75
  9.  
  10.  
  11. Ok, I have to admit that some of the statistics in my last posting
  12. were slightly biased.  For example, the US produces far more military
  13. software than Japan.  The amount of paperwork involved in US military
  14. software is positively astounding, and it drives productivity rates
  15. through the floor.  Even so, the quality numbers and sheer volume of
  16. programming staffs indicate that there are several other countries 
  17. actively seeking to dominate the software engineering field.
  18.  
  19. It is my opinion that we need to work long and hard at improving
  20. our productivity and our quality standards.
  21.  
  22. Front-loading the process is the first, and most obvious method of
  23. doing this.  More time spent in defining the requirements of a
  24. product, more time spent in designing a system, can mean less time
  25. spent in coding it.  In fact, through the use of highly structured
  26. designs and automatic code generators, we can almost completely 
  27. eliminate the time spent coding certain types of software.  This not
  28. only reduces the amount of time spent in development (and testing), it
  29. also completely eliminates certain classes of errors.  Automated tools
  30. could be developed that would guide our software engineers through the 
  31. design process and perform automated consistency checking at all levels,
  32. from requirements through low-level design, in much the same way that 
  33. hardware engineers use CAD tools.  Of course, once these tools are
  34. available, there is nothing to keep our foreign competitors from 
  35. using them as well.
  36.  
  37. We also need to provide all of our software engineers with extensive
  38. training in the most effective methods available for producing sofware,
  39. and provide them with the tools to make use of those methods.  This
  40. is going to require a substantial investment on the part of our
  41. management, which may be very hard for them to swallow, especially
  42. given the short-term profit motive currently running rmapant in US
  43. industry.  The tools required include both the software tools that 
  44. will allow us to front-load our process to this extent, and also
  45. the hardware tools for those tools to run on.  This means high-speed
  46. graphical workstations and high-speed networks, including a national
  47. data infrastructure such as ISDN and/or NREN.  Antiquated methods of
  48. software development using 25x80 ascii terminals connected to a mini-
  49. or main-frame computer at 4800bps or 9600bps simply will not suffice
  50. for the software development needs of our future.  (Yes, I still see
  51. these types of arrangements being used for software development.)
  52.  
  53. Higher level languages that require fewer statements to accomplish
  54. the same functionality will go a long way to showing productivity 
  55. gains in the programming phase of software development, even if auto-
  56. mated code generators are not used.  Lower level languages should be
  57. used only at the lowest levels of hardware interfaces.
  58.  
  59. Software re-use is going to become one of the most effective methods
  60. of reducing software cost and improving software quality.  I have
  61. heard time and time again that software re-use is a fantasy, but I 
  62. see those same nay-sayers re-using software every day.  For example,
  63. most programmers I know use code fragments as templates for software
  64. with a similar purpose.  Had that software been developed with re-use
  65. in mind, it could have been incorporated into the new package code, 
  66. design, and test.  How many of us use math libraries or operating system
  67. calls to accomplish things without having to re-code them?  I see no
  68. technical reason for not designing software for re-use.
  69.  
  70. Of course, there are management reasons for not doing these things.
  71. I repeatedly hear managers saying, "Not on *MY* project," or, "We 
  72. don't have the time or manpower to design some other project's code."
  73. And yet, at the same time, I hear those same managers complaining that 
  74. their software development is taking too long and has far too many bugs
  75. in it.
  76.  
  77. Well, I guess I have ranted on long enough here, so how about those
  78. comments?  I know you are all just waiting to start pounding on those
  79. keyboards.
  80.  
  81. -- 
  82. Rob Schultz   At Home:                        At work:          +1 219 262 7206
  83.                       rms@andria.miles.com                        rms@miles.com
  84.       {uunet|iuvax}!gator!miles!andria!rms        {uunet|iuvax}!gator!miles!rms
  85.