Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!wuarchive!uunet!abvax!iccgcc!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: <4796.284d01e1@iccgcc.decnet.ab.com> Date: 5 Jun 91 20:23:12 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 Lines: 50 > <470 Followup-To: <470 Lines: 46 In article , jgautier@biscuit.ads.com (Jorge Gautier) writes: > 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. This is current thinking. What is "lots"? Do you have any proof that this is so? How much more expensive is it to maintain this code than create new code? > Another example: releasing > code without testing it is usually dangerous. What if it was designed using Cleanroom technology? Usually is the key word here. When do you test? How much? > 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. Assuming that the content of the functional specification is what the custome wants. [...] > 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. Good stuff. GXKambic The size and extent of this disclaimer is immeasurable.