ProductiveCoder

Quite obviously, a productive coder is one who grinds out more lines of code per unit of time. What's that you say ? Not really ?

Maybe like a productive cold....BobKing 2002.9.21

Organizations that measure productivity by counting lines of code get what they deserve.

I once worked with a software developer who probably had one of the highest code creation rates (C language) in this particular organization. Unfortunately the number of errors he created was an order of magnitude higher than the best software developer in terms of errors per thousand lines of code (KLOC). If I recall correctly we were looking at a rate of 20 to 30 errors per KLOC versus 2 to 3 errors per KLOC for the best developer who created the lowest rate of errors. The increased number of bugs from this developer increased the time for testing and re-testing by several months for this medium sized application. - JohnSuzuki 21-Sept-2002.

Did people on that project consider unit testing, code reviews, pair programming, etc., to stop the flow of new bugs? Or the simple step of requiring the person who creating bugs to fix the bugs ASAP before writing new code?

Someone on the XP usenet group mentioned that he's currently doing mostly refactoring on a project, and thus his "code production rate" is negative lines per day, as he removes duplication and improves the design.

KeithRay 2002.09.21

Trying to measure productive code *might* be a place we can use earned value measurements in software. When you measure earned value, you measure completed work. As long as you don't stop with LOC, but continue on until you have integrated tested code, then you can measure earned value. The problem is the coder isn't the only person who contributed to the final code. The requirements writer, the designer, the tester all contributed to the final product. So, I guess I still don't know how to precisely measure earned value or programmer productivity.

Keith, when I teach my project management workshops, I show people the S curve of code development (start off slow, sharp increase, tail off). And, then I show them measurements of actual products. Projects that had low defects and high customer satisfaction had significant decreases in code size (on the order of 10-20%).

The first time I measured code decrease, I measured it on my code. I'd had a breakthrough of product understanding, and was "making my code go away". Since this was 20 years ago, and I had no version control system, I kept directories of what I would now call branches. I did a wc -l (the unix line count command), and realized that the more I understood the system, the more I could reduce the code. Up to a point, of course.

I then started measuring LOC, looking for the decrease in total LOC at the end of the project. If I don't see it, I'm pretty sure the developers have not finished understanding their creations. This is a guideline for me, NOT a rule :-)

JohannaRothman 2002.09.22

All this reminds me of my typing speed measurements when I took typing class in high school. Since errors resulted in subtractions from your raw speed, I wound up with minus ten words per minute. (I still got an A because I was the only boy in the class, and the teacher liked me. Sounds like nothing has changed, huh?) Somehow, I've managed to write 40+ books at minus ten words per minute - but, then, they were training me to be the one who fixed other people's errors, not the one who created errors for other people to fix - and certainly not the content producer.

Even so, the idea of subtracting equivalent LOC for errors found in the code might be a good improvement to the measurement. Just add in all the extra work it costs around the organization. And, if you add in customer work, about half the developers I know would wind up with negative LOC counts. - JerryWeinberg 2002.09.22

Updated: Monday, September 23, 2002