home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / volume.30 / text0001.txt < prev    next >
Encoding:
Text File  |  1993-03-11  |  1.7 KB  |  33 lines

  1. Submitted-by: jfh@rpp386.uucp (John F. Haugh II)
  2.  
  3. In article <1hjd0sINNobl@ftp.UU.NET> knighten@SSD.intel.com (Bob Knighten) writes:
  4. >This is a commonly expressed claim ("standards should codify existing
  5. >practice") and it may even be true for software, but I would certainly like to
  6. >hear some justification.  Certainly it is not true for a great many other
  7. >standards, such as many computer hardware standards, standards for electrical
  8. >fixtures and building standards, where specification of a standard often
  9. >preceeds the existence of any product.  Indeed there are numerous situations
  10. >where this is enforced by law.
  11.  
  12. I know that in certain of these circumstances, where the standard predates
  13. the production of something which meets these standards, that the standard
  14. is derived from an existing standard plus some incremental refinement.  The
  15. area I am most familiar with is the American Bureau of Shipping standards
  16. as they apply to maritime vessels.  The size of a piece of steel in a certain
  17. location in a ship is not pulled out of thin air.  Rather, that piece of
  18. steel is specified based on existing practice, and the specification is
  19. altered using practical experience (like, did any boats built that way sink
  20. recently ...), not the desire to make life easier on steel foundries.
  21.  
  22. Were software standards derived in a manner similar to those produced by
  23. engineers in the more physical disciplines, perhaps software would be as
  24. compatible as telephone equipment and as reliable as a screwdriver ...
  25.  
  26. -- 
  27. John F. Haugh II                  [  TSAKC  ] !'s: ...!cs.utexas.edu!rpp386!jfh
  28. Ma Bell: (512) 251-2151           [ DoF #17 ]        @'s: jfh@rpp386.cactus.org
  29.  
  30.  
  31. Volume-Number: Volume 30, Number 2
  32.  
  33.