Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!swrinde!elroy.jpl.nasa.gov!decwrl!ads.com!saturn!jgautier From: jgautier@vangogh.ads.com (Jorge Gautier) Newsgroups: comp.software-eng Subject: Re: Personal growth and software engineering! Message-ID: Date: 8 Apr 91 23:49:34 GMT References: <9233@castle.ed.ac.uk> <1991Mar25.164133.29674@unislc.uucp> <549@tivoli.UUCP> Sender: usenet@ads.com (USENET News) Distribution: comp.software-eng Organization: Advanced Decision Systems, Mountain View, CA 94043, +1 (415) 960-7300 Lines: 77 In-Reply-To: alan@tivoli.UUCP's message of 5 Apr 91 19:10:23 GMT In article <549@tivoli.UUCP> alan@tivoli.UUCP (Alan R. Weiss) writes: >> No. Realization that the process or skill needs to be controlled is >> the first step towards control of the same. > > Bzzt. Wrong. The *first* step is identifying a problem in specific terms. > If there is not a problem, why bother? Note that this can include a > desire to increase productivity and/or quality. But you better be specific. > And numbers help here. The problem is the cost (in the most inclusive sense) of producing software. The numbers are at least monetary units and time units. Cost is related to process and system complexity. Since we wouldn't want to unnecessarily restrict ourselves to low complexity systems, we could improve the efficiency of the process (if we wanted to ;-). > If the metrics are bogus, then fix them by including the workers > in the process. In this case, "process" can mean calling a short > meeting, identifying dumb metrics, and coming up with meaningful ones. I don't know how to fix them, and I'm not particularly interested in figuring it out. Most processes are too informal to measure effectively. By effectively I mean that the metric should give you a nonambiguous message of what needs to be done given your intentions. For example, a coverage measuring tool measures the amount of code exercised by tests. If you want 90% coverage and you are getting 30%, the message is clear: write more and/or better tests. Testing is a well formalized process and can be meaningfully measured in this way. Contrast this with metrics like "we wrote a 1000 line program in three months and found 50 defects." What does this tell you? Is it good or bad? Should you do anything about your process because of these metrics? Lines of code, hours of programming and number of defects are so variable and dependent on so many informal factors that their effectiveness is limited. Really, am I the only one who can see the difference between these two examples? > But to discredit measurements because some are unreliable is to > throw the baby out with the bath water. Measurement is a useful approach in some circumstances. However, if measurements don't "tell you what to do" about your process they can be misleading at best. > If I were YOUR manager, I would have YOU measure yourself. And rest > assured, you would not question my future because of it :-) > You *might* even appreciate the chance to improve your skills > (and therefore your value) in a non-threatening fashion. How much are you paying for this self-measurement job? :-) Thanks, but no, thanks. I prefer to construct software rather than measure something that I don't even know what it is. I already work regularly on improving my skills as a matter of principle. > Clearly the absence of measurements relegates software creation to > the arts, rather than as an engineering and/or scientific discipline. > If this is your desire, you should make sure you get what you > bargained for. The absence of formality in software development processes is what makes their measurement unreliable and relegates software creation to the arts. I don't desire absence of measurements, only of unreliable ones. > No one is more aware than I of the role of people in the process. > But treating programmers like anything less than professionals is insulting. > Surely you don't mean this, do you Jorge? :-) No :-). (BTW, I love the way the word "professional" is used to keep programmers "in line". This is not the first time I've seen it done. Students, take note; this is usually not taught in school. :-) Programmers may be professionals, but they are not engineers. Just introducing some random kind of measurement into their process won't automatically make them engineers. -- Jorge A. Gautier| "The enemy is at the gate. And the enemy is the human mind jgautier@ads.com| itself--or lack of it--on this planet." -General Boy DISCLAIMER: All statements in this message are false.