Path: utzoo!attcan!uunet!samsung!zaphod.mps.ohio-state.edu!wuarchive!decwrl!nsc!amdahl!netcom!mcmahan From: mcmahan@netcom.UUCP (Dave Mc Mahan) Newsgroups: comp.software-eng Subject: Re: How do you measure code quality? Message-ID: <11113@netcom.UUCP> Date: 27 Jun 90 06:25:21 GMT References: <10865@netcom.UUCP> Distribution: comp Organization: Dave McMahan @ NetCom Services Lines: 30 In a previous article, cimshop!davidm@uunet.UU.NET (David S. Masterson) writes: >In article <10865@netcom.UUCP> mcmahan@netcom.UUCP (Dave Mc Mahan) writes: > > Personally, I think there is only one standard, and it is set by the 'user' > of the code. If the software does what it is supposed to do, the user will > be happy. > >This seems all right for an internal, "captive" user, but how about the >end-user of a software product? Must he buy the product only to determine >that he isn't happy with it? Isn't that a little late? Yes, especially if s/he didn't buy from a place that has a money back guarantee! I'm a firm believer that every buyer is responsible for determining the 'fitness' for any program purchased. I always try to demo a piece of software before I spend money. However, fairness aside, I still stick to my original premise that the yardstick for determining if the software is 'quality' or not belongs to the user. Who else knows better then s/he what problem needs to be solved. Finding out that the 'quality' is lacking after the purchase is indeed an unfortunate suprise, but not related to whether or not you have just purchased a 'quality' product. The product was either fit or unfit before the purchase. Finding out before is always better (although usually harder) than finding out after the purchase. Caveat Emptor!! >David Masterson Consilium, Inc. -dave