stability

[Walter Bright]

Bill Baxter wrote:
> It's little better I think if you assign points to bugs based on their 
> estimated difficulty of fixing and relative significance.

A bug list is a great way to organize and manage what to do next on the 
product. It is *terrible* as a numeric measure of quality. Never 
underestimate the ability of people to manipulate any objective measure 
of their performance.


> Still, in a corporate setting I can see there being issues even with a 
> points system.  Who decides how many points it's worth, what if a bug 
> turns out to be harder than anticipated, somebody could still try to 
> file and close a million trivial bugs to game the system.  But in an 
> environment where people actually care about the software they're 
> creating, and not all just trying to get promoted, I think points for 
> bugs can be a useful motivator.

The situations I've seen it tried in were not populated by unmotivated, 
incompetent engineers. The problem is the bug count is a corrupting 
influence, that after a while even the best succumb to.

I also saw a company that decided to grade its staff on minimizing 
inventory, because they were going to do "just in time" production. 
Well, the inventory got minimized, all right. A $10,000 sale would be 
lost because a 5 cent component was out of stock. (It got so bad that 
some of the engineers would actually buy critical components on their 
own nickel and keep a supply in their desk drawers.)

You've got to be very, very careful about grading people on some sort of 
objective metric. Because you'll get what you grade for, and might find 
out that it's not what you wanted at all (like all those twilight zone 
episodes where the person gets 3 wishes from the devil).