Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!apple!netcomsv!jls
From: jls@netcom.COM (Jim Showalter)
Newsgroups: comp.software-eng
Subject: Re: bridge building and discipline
Message-ID: <1991May21.223401.27023@netcom.COM>
Date: 21 May 91 22:34:01 GMT
References: <24563@unix.SRI.COM>
Organization: Netcom - Online Communication Services  UNIX System {408 241-9760 guest}
Lines: 64

>The advantage of metrics is that they facilitate a common ground for discussion
>between people and organizations.  You may disagree with me what the numbers
>mean, but we now have a common reference point.  The real trick to metrics is
>really just to start measuring *something*.  After trial and error you will
>arrive at "things" to track that will work for you and your organization (all
>of which are peculiar, IMHO).  What you are after are "early warnings" of
>impending problems that allow you time to fix them up front - before they
>are problems.  I would argue that someone with a lot of experience that isn't
>using metrics consciously is actually using them unconsciously (or intuitively)

Indeed. Think of metrics like the SAT college admissions test. It doesn't
purport to measure intelligence, it just claims to be a reasonably accurate
predictor of success in college. The evidence supports this claim: SOMETHING
that has some bearing on success in college is being measured by the SAT's,
since those with lower scores tend to do worse in college. So, here is an
example of a metric that seems to be a good early warning of future success
in college, and yet WHY it does so has never been established. Basically,
they tuned the tests experimentally to get the correlation they desired:
the tests were retro-engineered from the results. There is no reason to
assume that similar techniques will not work for software metrics.

Furthermore, the above discussion assumes that there are no existing metrics
that have any validity, a claim I'm quite suspicious of. I should think
that, at a minimum, metrics that measure the percent reuse, the number of
bugs per source line, the number of edit/compile/debug iterations per
component, and the degree of complexity per component should all be useful
and valid measures of project sanity. The argument that bugs per line is
meaningless because complexity varies from unit to unit can be partially
offset by normalization relative to the complexity measure for the unit;
more importantly, even if this normalization is not performed, I think it
is of GREAT value to a project manager to be able to peer into the code
for a project and find, at a glance, the top 5% in terms of bugginess,
iterations, and complexity. What if, for example, having such metrics on
hand the project manager was able to determine that the vast majority of
the problems seemed to be confined to a couple of subsystems (say, the
user interface and the database)? Wouldn't this be a good thing to know?
If I had that kind of information on hand as a manager, the next logical
step would be to do some additional data collection to try to determine
if the subsystems in question needed more resource, a longer schedule,
a redesign, some diagnostic prototyping, etc. The metrics would allow
me to FOCUS my attention where it was most needed. Without such metrics,
I'm basically flying blindfolded.

There sure is a lot of resistance to this rather simple idea. I think
it comes from the same source as bad code in the first place: the ego-
driven hacker culture fearing that all the "fun" will be taken out
of programming if it has to become a real branch of engineering. And
yet, what an immature attitude this really is. If a project of which
one is a member is in trouble, it is in the best interests of all concerned
that steps be taken to bail out the project, right? If taking such
steps results in the exposure of incompetence, poor design, sloppy
coding, etc, tough--there is absolutely NO business case for allowing
such things to exist in the first place, let alone persist. It's not
a matter of cramping artistic expression: it's a simple matter of
running a business instead of an artists' collective. I'll believe
that discipline is a bad thing when I see hardware engineers, civil
engineers, mechanical engineers, and aerospace engineers start hacking
THEIR stuff together instead of following disciplined engineering
practices.
-- 
**************** JIM SHOWALTER, jls@netcom.com, (408) 243-0630 ****************
*Proven solutions to software problems. Consulting and training on all aspects*
*of software development. Management/process/methodology. Architecture/design/*
*reuse. Quality/productivity. Risk reduction. EFFECTIVE OO usage. Ada/C++.    *