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. 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. 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. 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. -- _ |\_ \| -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
