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> <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