xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) (07/06/90)
In article <CIMSHOP!DAVIDM.90Jul2005035@uunet.UU.NET> cimshop!davidm@uunet.UU.NET (David S. Masterson) writes: >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... As the employee, I'd hate this. Software people move around a lot more often than other folks, and return on investment comes after recovering expenses, when the responsible developer is long gone. Second, and worse, is the hot startup company that gets the first product (the one the idea for which got the venture capital in) through beta test, and started shipping, and promptly lays off most of the development team. Happened to a good friend of mine this week, and I'm still steamed, even though I saw it coming two months back. Result? He's not around when the return on investment for his code gets measured. Moral: in the software development business, make sure your incentives are not deferred, but show up in the old pay check two Fridays hence. I guess this has little to do with Software Engineering, except that churning staff makes for a bad product. Kent, the man from xanth. <xanthian@Zorch.SF-Bay.ORG> <xanthian@well.sf.ca.us>
davidm@uunet.UU.NET (David S. Masterson) (07/10/90)
In article <1990Jul6.102036.19546@zorch.SF-Bay.ORG> xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) writes: In article <CIMSHOP!DAVIDM.90Jul2005035@uunet.UU.NET> cimshop!davidm@uunet.UU.NET (David S. Masterson) writes: > >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... As the employee, I'd hate this. Software people move around a lot more often than other folks, and return on investment comes after recovering expenses, when the responsible developer is long gone. I'd hate it too. My point was that there seems to be no good (mediocre?) methodology for determining code quality (and, therefore, reward) up front. Even if there is, chances are that it is a rigorous approach and there is a distinct lack of drive to implement the tough stuff. Note the up until recent belief in object oriented development without strong object oriented analysis, design, measurement, etc... Second, and worse, is the hot startup company that gets the first product (the one the idea for which got the venture capital in) through beta test, and started shipping, and promptly lays off most of the development team. Happened to a good friend of mine this week, and I'm still steamed, even though I saw it coming two months back. Result? He's not around when the return on investment for his code gets measured. All I can say to this is **dumb**. -- =================================================================== 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!"