Re: measuring job performance

From: Nick Landsberg (hukolau_at_NOSPAM.att.net)
Date: 04/06/04 

Date: Mon, 05 Apr 2004 22:55:48 GMT

Gawnsoft wrote:

> On Sun, 04 Apr 2004 21:16:40 GMT, "Rogue Petunia"
> <roguepetunia@nospam.com> wrote (more or less):
>
>
>>Hello,
>>I'd like to hear your ideas on how to measure a programmer's job
>>performance, particularly the output. Our company requires each employee to
>>set goals for the year. My manager has told me that my output must increase
>>and this must be one of my goals for this year. This is a vague, nebulous
>>statement. How can one quantify this?
>>
>>If I were a salesperson, I could say, my goal is to sell 10% more vacuums.
>>Programming is different. Can't say, my goal is to complete 5 projects this
>>year because the size of projects vary.
>>
>>I don't believe in LOC (lines of code) as a job performance metric because a
>>good programmer writes compact, efficient code that leads to application
>>stability. Sprawling, uncontrolled code full of workarounds might have a
>>lot more lines but it's worse.
>>
>>Our company's goal setting guidelines encourage that we set quantifiable
>>goals. A goal such as, "to improve technical skills" is a poor goal. It
>>would be better stated as, "to learn COM+". And even that is not so good
>>because what constitutes having "learned" something? Perhaps, "to write a
>>COM+ component" really narrows it down and leaves little room for
>>interpretation. At the year end performance review you've either written a
>>COM+ component or you haven't. You've either met the goal or you haven't.
>>
>>I'd like to hear from those of you with experience in a corporate setting
>>where goal setting and performance reviews are standard fare. Do you have
>>suggestions on how to quantify the goal of "to increase my output".
>
>
> Why not make the measurements to do with quality, not quantity?

Very good point!

>
> e.g. 'fewer bugs discovered by end-users in code I have created this
> year vs. code I created last year'.

This is not an individual metric but on organizational
metric. It might be that the acceptance test group/organization
is poorly staffed and thus did not catch the bugs.

>
> 'Fewer bugs per 1000 lines of code escaping to Acceptance testing'.

This is better, but still has the LOC spit in it.
IMO, a "first pass rate" should be considered.
By this I mean the percentage of acceptance tests
which passed the first time. Each acceptance
test which fails causes another iteration of
code, unit test, debug, submit and (possibly)
retest that which has already passed to make
sure that you didn't break anything. This takes
not only the developers time, but testers time as
well.

Note that while you are fixing this "bug", you
are probably not working on your *next* assignment
which makes you look less productive in *that* phase.

This should also be tempered with some kind
of "bug severity" scale, e.g.
Severity 1: Major required functionality does not work.
("It don't steekeeng work at all!")
Severity 2: It fails under the following
circumstances but I can work around it.
("If you can't fix it, we'll document the
workaround in the user documentation, but
we would rather not because it is a PITA
and would make us look stupid.")
Severity 3: Once in a while I get this glitch.
("If it happens to customers, we'll blame it
on Micro$oft.")
Severity 4: Wouldn't it be nice if it also did ...
("Don't do nothing yet! We'll try to figure out a way
to charge customers for this as an enhancement.")

(feel free to disagree with the scale, it's just
one possible categorization. :) )

>
> Or 'higher % coverage of your code by your unit tests this year than
> next'.

I feel that this is subsumed under the "first pass rate"
noted above, i.e. this may be a means to get a better
"first pass rate."

>
> Or something like 'my coding practices to become 5% more Agile than
> before' :-)
>
>

No comment other than to say "how do you measure
the 5%?" :)

>
> Cheers,
> Euan
> Gawnsoft: http://www.gawnsoft.co.sr
> Symbian/Epoc wiki: http://html.dnsalias.net:1122
> Smalltalk links (harvested from comp.lang.smalltalk) http://html.dnsalias.net/gawnsoft/smalltalk 

-- 
"It is impossible to make anything foolproof
because fools are so ingenious"
  - A. Bloch

Relevant Pages

  • Re: POL Re: Ethanol Powered Aircraft
    ... Not by a long shot.. ... But in terms of your definition (keep setting new goals), ... The goal setting is more related to a strong work ethic. ... Others set goals too far in advance and end up ...
    (rec.aviation.piloting)
  • Re: 2008 Mileage Goals
    ... bicycling weather of the year. ... I don't want to set goals that I can not make. ... And to cut down on the obsession part, ...
    (rec.bicycles.misc)
  • Success
    ... In our younger years we set goals, founded in our ignorance. ... Its bogus aspects fail instantly for the most part and do not ...
    (soc.retirement)
  • Success
    ... In our younger years we set goals, founded in our ignorance. ... Its bogus aspects fail instantly for the most part and do not ...
    (sci.research.careers)
Loading