Path: utzoo!attcan!uunet!cimshop!davidm From: cimshop!davidm@uunet.UU.NET (David S. Masterson) Newsgroups: comp.software-eng Subject: Re: How do you measure code quality? Message-ID: Date: 2 Jul 90 07:50:35 GMT References: <10865@netcom.UUCP> <1990Jul2.000639.14545@zorch.SF-Bay.ORG> Sender: davidm@cimshop.UUCP Distribution: comp Organization: Consilium Inc., Mountain View, California. Lines: 26 In-reply-to: xanthian@zorch.SF-Bay.ORG's message of 2 Jul 90 00:06:39 GMT In article <1990Jul2.000639.14545@zorch.SF-Bay.ORG> xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) writes: Moreover, if management wants to reward creation of quality code (what a novel concept, but how wise), you'd better have a lot more objective was of measuring quality. Bugs reported per time period, effort per bug to repair, changes requested per time period, time DIV complexity to make those changes, several metrics (granted they're mostly snake oil and predict little; let's improve them), all need to be considered before bonuses are paid. Perhaps its better for management to reward a percentage of the return on the code than worry about the quality of the code. No measurements, no predictions, just simple sharing of returns (product sales, money saved, etc.). I know this sort of contradicts what I've said before, but what the hey... Actually, I think its more important to be able to predict outcomes with some measure of accuracy going into a project than coming out of one (when you would normally decide on rewards). -- =================================================================== David Masterson Consilium, Inc. uunet!cimshop!davidm Mt. View, CA 94043 =================================================================== "If someone thinks they know what I said, then I didn't say it!"