Re: Productivity Metrics

Subject: Re: Productivity Metrics
From: Bruce Byfield <bbyfield -at- axionet -dot- com>
To: techwr-l digest recipients <techwr-l -at- lists -dot- raycomm -dot- com>
Date: Tue, 11 Jul 2000 13:39:16 -0700

"Elna Tymes" <etymes -at- lts -dot- com> wrote:

>The biggest problem with productivity measurements is that it's measuring output
>from a process that is usually not well defined or contained. It's one thing to
>measure pages per day or character strokes per minute, but that assumes that the
>source material is (a) available, (b) accurate, and (c) not going to change.
>Most of us in the software industry have armloads of war stories about trying to
>write about a product that has sketchy or no specs, development schedules that
>are routinely ignored, review processes that turn into endless loops of
>correction/rewrite, and prima donna developers who think they can write. Since
>half of most productivity measures is the time variable, the ability to work to
>some sort of reasonable schedule is an assumption - but one that in my
>experience is subject to far too many unpredictable outside forces. To be held
>accountable to a schedule that is subject to the whims of others is
>unreasonable. To thus consider it as a factor in productivity metrics is simply

I suspect that the problem is not with metrics, so much as how
they are used. If they are used as a rough guide for planning
purposes, they have their uses. As Rebecca said, if you're a
contractor, metrics are unavoidable; for some reason, companies
have an aversion to hiring you for open-ended projects. There's
only a problem if they're used narrowly, and everyone is held to
a narow range of circumstances.

Instead of providing a single metric, I like to provide several,
to show how the job could change according to the degree of
co-operation I get and what the company wants. Then, if I'm in
the kind of situation that Elna describes (and, like many
writers, I often am), I can point to my initial estimates and
explain that there's an overrun because things didn't happen that
were supposed to.

In short, the problem isn't with the tool so much as with
inflexible minds - and they're even more common than time
overruns on projects.

Bruce Byfield, Outlaw Communications
Contributing Editor, Maximum Linux
bbyfield -at- axionet -dot- com | Tel: 604.421.7189

"At the sick bed of Cuhullain,
We'll kneel and say a prayer,
When the ghosts are rattling at the door
And the devil's in the chair."
- The Pogues

Previous by Author: Re: E-stuff
Next by Author: Re: naming conventions for images
Previous by Thread: RE: Productivity Metrics
Next by Thread: Re: Productivity Metrics

What this post helpful? Share it with friends and colleagues:

Sponsored Ads