Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!elroy.jpl.nasa.gov!ncar!ico!rcd From: rcd@ico.isc.com (Dick Dunn) Newsgroups: comp.software-eng Subject: Re: Code inspections Summary: scorn "average" Message-ID: <1991Feb5.234103.29@ico.isc.com> Date: 5 Feb 91 23:41:03 GMT References: <14964@megatest.UUCP> <1991Jan28.225231.19444@ico.isc.com> <309@smds.UUCP> Organization: Interactive Systems Corporation, Boulder, CO Lines: 57 rh@smds.UUCP (Richard Harter) writes: > [I wrote, about the matter of reviewing 150 lines/day] > > A halfway-decent programmer can produce several > > times that 150 l/d figure...proceeding through anything at 20 lines/hour > > (that's 3 minutes per line, effectively???) is too slow to feel productive. > Reality check time. One can write several hundred lines of code in one > session. However that is exceptional. Typical industry figures are > 5-10 thousand lines of delivered code per year which is 25-50 lines/day. > Programmers who can average 100 lines/day are quite exceptional. I agree so far...but that's making the case for slow code reviews even tougher. The more "exceptional" the programmer is, the deeper you cut into productivity. > Since many of us can and have written several hundred lines of code at > one sitting, why is the average rate so low? One obvious reason is that > once you have written the code you have to compile and debug it. Another > is that a fair percentage of ones time gets eaten up in non-programming > activities... I think these factors, and others, are taken into account. Certainly when I say one can write several hundred lines in a day, I *don't* just mean plunking the characters into a source file! I mean producing finished code. The issue you're leaving out is that the best programmers are some two orders of magnitude more productive than average. This is an unusual situation, in the sense that you don't find this range of productivity difference in many other disciplines. While we do have to take account of the "average" programmer, I don't think we should be developing processes which work so much to the disadvantage of the exceptional programmer. > ...In a > decent code review you have to verify that all external interfaces are > correctly referenced and used,... Most of this should be handled automatically, shouldn't it? Perhaps I'm missing your point. >...that each line of code is correct... This is at far too low a level for a useful code review. Get better pro- grammers who can be trusted to write code that doesn't need microscopic examination. > ...You also want to verify that the modular > decomposition is appropriate and that the modules fit into the over-all > design... But isn't a "code review" too late for this? Why would you be re-examining the decomposition (the framework) after you've built all the detail onto the framework. I'd rather sit down before coding and bounce ideas off someone to see if the code layout makes sense *before* I write it. Whether you're building top-down, bottom-up, interior-out, or edges-in, the level you're working on needs to be sound before you move to the next level. -- Dick Dunn rcd@ico.isc.com -or- ico!rcd Boulder, CO (303)449-2870 ...Don't lend your hand to raise no flag atop no ship of fools.