Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!apple!netcom!mcmahan From: mcmahan@netcom.UUCP (Dave Mc Mahan) Newsgroups: comp.software-eng Subject: Re: How do you measure code quality? Message-ID: <11427@netcom.UUCP> Date: 1 Jul 90 22:05:33 GMT References: <11113@netcom.UUCP> <926@gistdev.gist.com> Distribution: comp Organization: Dave McMahan @ NetCom Services Lines: 32 In a previous article, flint@gistdev.gist.com (Flint Pellett) writes: >On the issue of "quality is in the eye of the user" only: the problem >with that as the sole measure of quality is that it is not a stable >"measure", it's like a rubber yardstick. For example, say that I buy >a new car, and I and several million other owners are completely happy >with it for two years. Then we find out on the news that our cars are >unsafe if we ever need to perform a quick turn to the left, and will >always roll over. Overnight the user satisfaction with the product >drops to half what it was: can you claim that the quality of the >product changed? I contend that the quality was constant (and not >very good) but by measuring only how the users felt about it I misled >myself. To really know what the quality of the product is (regardless >of what hat I'm wearing) I need to examine several things, not just one. Yes, in my original posting I mentioned that this method of measurement is one of the harder ones to quantify, as the user can't even tell you what is good or bad about the program in detailed words. Things like, "well, it just doesn't seem to make sense", or "I like it, but it's not really what I want" don't help me too much. Changing expectations are always a job hazzard. In more formal descriptions, this is called "requesting more features". The yardstick can change (since people are fickle) and you can't really do to much about it, since there was never any formal acceptance by the user as to what the program would do. If there had been, the programmer/engineer can use that as justification for more money, since the program now has to do more things. I still stand by my original premise, however. If it doesn't do what the customer wants and needs, the program can use adjustment. >Flint Pellett, Global Information Systems Technology, Inc. -dave