Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!rpi!think.com!sdd.hp.com!elroy.jpl.nasa.gov!decwrl!ads.com!saturn!jgautier From: jgautier@vangogh.ads.com (Jorge Gautier) Newsgroups: comp.software-eng Subject: Re: bridge building and discipline Message-ID: Date: 6 Jun 91 22:49:36 GMT References: <1259@grapevine.EBay.Sun.COM> <9105012313.AA23259@enuxha.eas.asu.edu> <1991May3.142824.208@keinstr.uucp> <1991May3.234349.14026@auto-trol.com> <4504.28267bad@iccgcc.decnet.ab.com> <1991May9.053311.800@netcom.COM> <4563.282e83ea@iccgcc.decnet.a <4796. Sender: usenet@ads.com (USENET News) Organization: Advanced Decision Systems, Mountain View, CA 94043, +1 (415) 960-7300 Lines: 39 In-Reply-To: kambic@iccgcc.decnet.ab.com's message of 5 Jun 91 20:23:12 GMT In article <4796.284d01e1@iccgcc.decnet.ab.com> kambic@iccgcc.decnet.ab.com (George X. Kambic, Allen-Bradley Inc.) writes: > > What are the quantitative > > metrics that can predict the problems/cost of bad design, bad code or > > bad process, and take into account problem and project idiosyncracies? > > This is not a rhethorical question, I really would like to see > > something more formalized along these lines. Until then, I will trust > > qualitative information more than the quantitative metrics I have seen > > in application. > > I think I understand the point you are making. IMHO we have got to start > somewhere, and a lot of the first guesses are going to be wrong. But since the > science of developing software isn't around to help yet, maybe we need to begin > to do some measurements/correlations to put in place some pragmatic/heuristic > rules to point the way. We're Brahe, heading towards Kepler, but not Newton > yet. That's just what my examples were, heuristics. They are not proven or foolproof. A lot of these rules seem to be problem/situation dependent, i.e., they need more specialized preconditions in order to obtain the desired results. But what else do we have? I tend to be skeptical of people who claim to have THE method that is guaranteed to produce cheap good software on time. As far as I know, all we have are heuristics, and judging from the state of the practice, not very good ones at that. I would think that a method guaranteeing optimal decisions about software development activities w.r.t. cost, quality and schedule would be famous by now. Measurements and correlations gathering by those who are directly involved in making decisions about how software is designed, implemented and verified are small but important steps towards a science of software. Unfortunately, not everyone understands that these measurements and correlations are not perfect, they are subject to revision and they do not (yet?) fully support decision making in software development projects. We also need people who can make good decisions no matter what the numbers "say." -- 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.