Friday, 29 March, 2002
Measuring Programmer Productivity
Slashdot last week ran a thread linkingthis article about programmer productivity. The linked article is mostly fluff, but the Slashdot thread had some interesting discussion. Like everything Slashdot related, the signal to noise ratio is terrible. What I found especially troubling, though, is the number of so-called programmers who insist that it's not possible to measure productivity in any objective way. That's pure B.S., and anybody who says different is probably trying to sell you something on an open time and materials contract. Don't fall for it. It's the same tired argument about "art" and "unpredictable technical problems" that the fly-by-night operators and self-proclaimed "hackers" give for not being on a schedule.
If it's not possible to measure a programmer's productivity, then there's no objective way to say that one programmer is more productive than another. If that's the case, then all programmers should be paid the same. That would make the Free Software activists happy, wouldn't it?
There are plenty of objective ways to measure a programmer's productivity. None of them are perfect, but they're all better than no measure at all. If you're running a development team, and you're not measuring your team's productivity, then it's going to be very difficult to improve, or even tell if your team is keeping pace with last year. Start with the article linked above, wade through the crap on the Slashdot thread to find the good stuff. Then pick up some books, learn a little about the subject, and start keeping track of your team's progress. I think you'll notice a marked improvement in a relatively short time—as little as six to eight weeks.