Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!elroy.jpl.nasa.gov!ames!ads.com!saturn!jgautier From: jgautier@biscuit.ads.com (Jorge Gautier) Newsgroups: comp.software-eng Subject: Re: bridge building and discipline Message-ID: Date: 1 Jun 91 21:14:01 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> <470 Sender: usenet@ads.com (USENET News) Followup-To: <4639. Organization: Advanced Decision Systems, Mountain View, CA 94043, +1 (415) 960-7300 Lines: 37 In-Reply-To: kambic@iccgcc.decnet.ab.com's message of 29 May 91 14:19:20 GMT In article <4708.28437219@iccgcc.decnet.ab.com> kambic@iccgcc.decnet.ab.com (George X. Kambic, Allen-Bradley Inc.) writes: > Interesting point. What qualitative information do you collect, and how do you > interpret it? Nothing too fancy, just things that are mostly obvious to anyone who has developed or maintained software. For example, a piece of code with lots of global variables, hidden inheritance hierarchies, spaghetti control flow and no design documentation or internal comments will be difficult to maintain. Another example: releasing code without testing it is usually dangerous. It can even be based on theory, like for example, trying to recognize C statements incrementally without a token stream that includes both EOFs. If you see things like this in your project, you may be in for some interesting times. Conversely, if you see well-organized, documented and readable code, regression testing before release, or designs based on well-established theory, many problems are prevented and it gives you a little more confidence in the project. > Not trying to be funny here, but is it 2x, 10x or 100x more > valuable than quantitative information? Better yet, what relative worth does > it have to specific metrics? Guess I am trying to quantify qualitative > indicators, but this would help point to where we should be spending our time > in assessing sw projects. Well, I just haven't seen any quantitative information that will help me predict the kinds of problems that I can predict based on information like the examples above. 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. -- 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.