On Tue, Jun 25, 2002 at 11:40:28PM -0500, Joel Schneider wrote: > Interesting story, but my opinion is that this story does not compare > apples-to-apples. Among our virtuoso software developer's activities, I > saw no mention of gathering requirements from the end users, summarizing > technical options for decision makers (aka PHBs), defining test cases, > or writing user documentation. Like I said, not apples-to-apples. How do you figure? I don't see any mention of the other guys doing any of these things either. They start off with "churning out preliminary reports and problem analyses" and "when tested [Charles's code] does everything required in the specifications", which implies that Charles had a spec, even if he didn't write it himself. > Also, lines of code (LOC) is not a reliable measure of programming > productivity. Fastest way to generate lots of LOC is copy/paste. Just > try maintaining that kind of mess, though (e.g. 10 similar programs > created with copy/paste). Substantial effort is commonly required to > refactor code and actually reduce the number of LOC. Uh, yeah. That appears to be one of the points of the story. One guy thinks hard about the program and writes a 500-line program which is superior to the 2,500-line program produced by 4-man team following the "PQR structured design methodology". I don't see anything to indicate that Rickert was promoting the use of LOC to measure productivity. (Yeah, the bosses in the story use it, but that use leads them to do exactly the wrong things. Hardly a ringing endorsement of the practice.) -- When we reduce our own liberties to stop terrorism, the terrorists have already won. - reverius Innocence is no protection when governments go bad. - Tom Swiss