Newsgroups: comp.software-eng
Path: utzoo!utgpu!news-server.csri.toronto.edu!torsqnt!jtsv16!blister!itcyyz!yrloc!rbe
From: rbe@yrloc.ipsa.reuter.COM (Robert Bernecky)
Subject: Re: bridge building and discipline
Message-ID: <1991May17.064623.23670@yrloc.ipsa.reuter.COM>
Reply-To: rbe@yrloc.ipsa.reuter.COM (Robert Bernecky)
Organization: SNake Island Research Inc, Toronto
References: <1991May9.053311.800@netcom.COM> <4563.282e83ea@iccgcc.decnet.ab.com> <JGAUTIER.91May13125016@vangogh.ads.com> <1991May14.150350.2837@den.mmc.com>
Distribution: na
Date: Fri, 17 May 91 06:46:23 GMT

In article <1991May14.150350.2837@den.mmc.com> kummer@possum.den.mmc.com (Jim Kummer) writes:
>>I think the desire for metrics is an admission by management types
>>that they really don't know what's going on in their projects.  Good
>>managers are able to tell if the project goals are being met, who's
>>doing well and who's screwing up without any metrics.  Metrics mania
>>indicates that someone doesn't understand software development and/or
>>they're desperate to figure out what's causing poor quality or project
>>failure.


I thought this was true for a long time, even when I was running a group
of about 25 people responsible for the design, development, and  support of
SHARP APL, which was used for some very critical applications, such as 
merchant banks dealing in large amounts of $$. 

We developers had an attitude that "we knew what we were doing, and how 
long it would take, etc".

Charles Chandler was on the receiving end of customer flak, and spent a lot
of time convincing us that without measurement, we could NOT make 
such claims.    It took me more than 20 years in the software biz to 
realize he was right. 

Furthermore, Chan, and HIroshi Isobe, of Hitachi, led the way in 
encouraging us to adopt  formal testing of our code. Isobe was, in fact,
incredulous, that we allowed code to escape without formal review.

We (developers) had an ego problem, which might be stated as:
   "Why should I spent time writing test suites, when I could be writing
      new code? I KNOW my code works!"

I instigated a program at I.P. Sharp to require a minimal degree of
code coverage of all changed modules, and the results were surprising to 
all of us:
   My own "extensivelyl tested" code, when I subjected it to simple 
     code coverage tests: "Provide a suite which executes ALL instructions
       in the code". (not even testing all paths..!)

     showed up a number of system crash bugs, even though the code had 
      been running for several months on internal systems.

Other people in thegroup were, although initially skeptical, became
enthused, for reasons similar to mine.

This approach also hold for project scheduling, in my bookL

if you educate programmers on When they are late, and try to learn WHY
they are late (Are programmers EVER early?) then they will 
adopt those methods which tell them why, and STOP BEING LATE>!

If you don't believe this, give it a FAIR try on a large project. If 
it works, great! If it doesn't work, try to understand why, 


Bob
>
>Metrics are not generally needed by the line supervisors and managers 
>directly over a project.  Rather, the metrics are needed by the 
>managers' managers, and theirs above them, who admittedly do not 
>know what's going on on the project.  In an atmosphere of mutual trust 
>and bilateral acceptance of responsibility, the need for metrics is 
>lessened, but not removed.
>
>---- Jim Kummer -------- kummer@pogo.den.mmc.com -----------
>disclaimer:  the above opinions are mine, and not necessarily those of 
>   anyone else.
>
>-- 
> 
>-- Regards ----- James Kummer --- Martin Marietta Corporation --
>----- kummer@pogo.den.mmc.com --- Information and Communication Systems --
> 

Robert Bernecky      rbe@yrloc.ipsa.reuter.com  bernecky@itrchq.itrc.on.ca 
Snake Island Research Inc  (416) 368-6944   FAX: (416) 360-4694 
18 Fifth Street, Ward's Island
Toronto, Ontario M5J 2B9 
Canada
