Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!ukma!usenet.ins.cwru.edu!abvax!iccgcc.decnet.ab.com!kambic From: kambic@iccgcc.decnet.ab.com (George X. Kambic, Allen-Bradley Inc.) Newsgroups: comp.software-eng Subject: Re: bridge building and discipline Message-ID: <1991Jun13.173211.4860@iccgcc.decnet.ab.com> Date: 13 Jun 91 22:32:11 GMT References: <1259@grapevine.EBay.Sun.COM> Lines: 42 In article , jgautier@vangogh.ads.com (Jorge Gautier) writes: > > 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 > produce cheap good software on time. Agreed > As far as I know, all we have > are heuristics, and judging from the state of the practice, not very > good ones at that. Not so sure about this. May be site dependent. > 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. Absolutely. > 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 Yep. Yep. Yep. As usual, we had to work through the words a few times to get pretty close agreement. GXKambic standard disclaimer