On Tue, December 12, 2006 1:08 am, Stewart Stremler wrote: > begin quoting Lan Barnes as of Sat, Dec 09, 2006 at 03:36:41PM -0800: >> > [snip] >> The best hope for quality cde is to contain defects in previous phases. >> Code reviews catch defects. Design reviews prevent defects. Good testing >> catches defects too late. >> >> 1:10:100 > > And waterfalls suck.
Let me say a kind word for waterfall. If I'm doing a humongous project with hundreds of managers and developers spread all over the world, I'm going to use something that looks a lot like waterfall, except it'll prob'ly be a spiral waterfall. Sometimes you have to go slow to go fast. > > Catching errors early is good. Building the system so that errors > caught late aren't intractable is better -- and is one of the reasons > we like modular programming: damage control. Well, important. But who said the two principles are mutually exclusive? "Shall I strive for phase containment, or modular design? One or the other. Einey meney miney ..." BTW, I've never done the numbers, but people I trust and know have, and the 1:10:100:1000 apparently really does work out as powers of 10. Except in our case -- medical devices -- catching something at the client site is not 10 times more expensive than catching it in final V&V: it's like "we just shut you down, *now* fix it and prove it's fixed, and BTW, you're the headline on the NYT business section" worse. > > A little thought up front is a good thing, yes. But it's wasteful to > try to catch as many defects as possible up front. That's almost as > bad as optimizing in the design stage, instead of using a profiler. > This is absolutely flat ass wrong, Stewart. I don't say that to you often -- this may be the first time -- but it is not "wasteful to try to catch as many defects as possible up front," it is the best and most cost effective approach. And it has zip to do with optimizing in the design stage. > I just got done with a week of testing. There were some defects that > we *could* have caught, with another week's worth of analysis up front, > but only took five minutes to fix during the test. And we'd've still > needed to run this test, so that analysis would have been wasted time. > > That being said... > > I know that there are other problems in the code that are going to > take much longer to fix, and should have been caught earlier. So > there's an argument for the other approach, too. I'm just not sure > that any sort of process could have prevented the pain we're going > to be feeling for that code, when the time comes. The longer you take to find a defect, the more its effects spread out, the more defects you introduce in your "five minutes to fix." This isn't Lan talking. Lan doesn't know much. This is an avalanche of opinion from brilliant, experienced professionals who have studied exactly this question over four decades. <snarky comment alert> You're talking just like a developer. <may god have mercy on me, I couldn't stop myself> -- Lan Barnes SCM Analyst Linux Guy Tcl/Tk Enthusiast Biodiesel Brewer -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
