Hi Dragan,

* SNIP *
I wander if there'll ever be any good measure of programmer's work. Even the "action points" may not be the best, because some of them require much more work than the others, some are trivial and some highly problematic; some are good from the first try and some require dozens of versions until the (ever-refined) goals are met.
>
>This leads to a further problem - the programmers always tend to work for money, and they instinctively do what's paid. If you pay them by the line, they'll copy&paste; if you pay them by the hour, they'll do extensive testing ad nauseam; if you pay them by action point, you'll have overcrowded menus, lots of tiny dialogues etc. I'm running a team of three coders here (I'm 4th) and we're simply trying to get work done, and this means done with least effort. If we feel something takes too much time, we try to find a way to make it automagically. We actually have no criteria for salary, except billable (not effective) hours. It's nowhere near good, but at least we're not wasting time over the problem. IMO, it has no permanent solution, only a series of partial and temporary solutions.

I brought Whil Hentzen's approach to people's attention because it is the first serious attempt I have seen to measure our work. Many of the issues that you list have been addressed. They only take clients who will pay for and sign off on an extremely detailed specification(changes after sign-off cost money, change timeframes, etc.). The value of a task(in action points) is determined using historical data that they have collected. They apparently do mainly fixed time/price work. Their approach allows any given deliverable to be assigned a fixed value (in dollars or action points(the relationship between the two being calculated from historical data)) which they can use to drive compensation. The system may have limited applicability and is not claimed to result in exact estimates (just the difference between a $15000 and a $30000 project. Naturally it requires effort to gather the historical information for such an approach, but if it allows for reasonably accurate estimates to be made via a repeatable process it would be a big improvement. If you (or any lurkers *g*) are interested more information is available in Whil Hentzen's "1999 Software Developer's Guide". I was hoping to get some feedback from developers who have attempted to implement such an approach.

At least I hoped it would be less of a waste of bandwidth *g* then the thread I was answering.

Later,
Ned