Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!mips!pacbell.com!att!bellcore!duncan
From: duncan@ctt.bellcore.com (Scott Duncan)
Newsgroups: comp.software-eng
Subject: Re: Personal growth and software engineering!
Keywords: Metrics, Measured-improvement, Quality
Message-ID: <1991Apr3.141729.2603@bellcore.bellcore.com>
Date: 3 Apr 91 14:17:29 GMT
References: <9233@castle.ed.ac.uk> <1991Mar25.164133.29674@unislc.uucp>
Sender: usenet@bellcore.bellcore.com (Poster of News)
Reply-To: duncan@ctt.bellcore.com (Scott Duncan)
Distribution: comp.software-eng
Organization: Computer Technology Transfer, Bellcore
Lines: 63

In article <1991Mar25.164133.29674@unislc.uucp> klb@unislc.UUCP (Keith L. Breinholt,B2G08) writes:
>
>Here's a simple fact of life--Measurement of a process or skill is the
>first step towards control of the same.

I disagree.  Recognition and acceptance that the process or skill needs to be
brought under control is the first step.  There is the "if it ain't broke
don't fix it" feeling of many software practitioners to overcome first.  In
some cases, measurements can be used to point out that something really is
"broken," from the perspective of clients/customers, even if the developers
don't see anything wrong.  However, this is usually product measures rather
than those which address the process.  And product measures generate most of
the heat in discussion about metrics, i.e., people get stuck in lines of code
and field defects and "productivity" goals, etc.

>Now, serious professionals are the type that like to improve their
>skills through whatever means is necessary.  If I have a method of
>measuring when I'm doing better versus when I screw up, I've just
>learned how to improve my skills.

That's you measuring you, though.  This is not the kinds of measurement efforts
often undertaken in large organizations.  Organizational goals and measures of
quality and productivity often end up at odds with individual ones.  The former
are more formal, visible, and based on quantifiable measures while the latter
are more likely to be informal, personally derived/tracked, and dependent upon
line management and peer feedback.  Both of these have validity to those who
use them, but most metrics "programs" are of the organizational variety, not
the local work group or individual improvement kind.

>Now if a supposed professional comes to me and tells me that they
>don't want to be measured (i.e. they don't want to improve).  I have
>real doubts about the future of that individual.

And I think it is not a matter of not wanting "to improve," but of not being
introduced to measurement with the sense that it is being offered for improve-
ment.  Most people get introduced to it in a way that suggests it is there for
evaluation purposes.  Or it is not clear why it is there, but the management
has heard/believes that "you can't manage what you can't measure" or some such
statement without thinking that this may apply to process and product but not
personnel.

In any event, there is a great difference between having folks come to you and
say
	"We notice your quality/productivity measures for the past
	quarter have been lower than hoped for, what are you going
	to do about it."

as opposed to saying

	"We notice your quality/productivity measures for the past 
        quarter have been lower than hoped for, what we do to help
        you improve."

Most metrics programs seem to start with the former message implied (largely
because the latter is not made explicit).

>Keith L. Breinholt		hellgate.utah.edu!uplherc!unislc!klb or
>Unisys, Unix Systems Group	kbreinho@peruvian.utah.edu

Speaking only for myself, of course, I am...
Scott P. Duncan (duncan@ctt.bellcore.com OR ...!bellcore!ctt!duncan)
                (Bellcore, 444 Hoes Lane  RRC 1H-210, Piscataway, NJ  08854)
                (908-699-3910 (w)   609-737-2945 (h))