If you meet requirements, do lines of code then become a viable measure of productivity?

I think most professional programmers get stuck in "blocking" operations (wait for requirements, wait for consensus on design details, wait for feedback, wait for some other developer) which limits their raw coding productivity and those that try to push past these blocks quickly start trading coding productivity for quality.<p>The SoC programmers on the other hand generally have all the big blocking operations taken care of ahead of time by the SoC managers and mentors, allowing them to focus just on the coding.

If you were doing Agile (and therefore had a reasonable metric of the relative size of each requirement), then a better metric might be your personal "velocity" of completed user stories, divided by the estimate amount.<p>I think a really cool metric would be who has the <i>fewest</i> lines of code per completed user story.

Somehow that story seems to fall short of it's possibilities. What programming languages have been used, for example - maybe the 20000 lines people where Java developers and the 4000 lines people where lisp programmers (or whatever)? And the argument for measuring the productivity by lines of code wasn't really made in the article, it just says it is a bad measure and then goes on to judge everything by that measure.<p>How long is the summer anyway, three months? So 20000 lines could be about 200 lines per day?