Productivity should be measured in terms of deliverables. A deliverable is a black box that satisfies a set of requirements (either from a requirements document or the design document based on those requirements) and is completed to a certain degree of error-free-ness by a certain date. Either you produced or you didn't.

Now, a deliverable can be an entire application or a small function. It can satisfy 100 requirements or part of 1. It can be a customer deliverable or an internal deliverable.

The reason I think in terms of deliverables is that LOC has nothing to do with the real world. For example, I write code differently depending on a huge number of factors:

• My expected environment
• My expected maintainers
• My expected reviewers
• My coworkers
• The style of code I'm allowed to write in
• How much I have to justify myself to my micro-manager

I have noticed that my LOC changes, sometimes by a factor of 10-20, depending on those factors. (The last factor usually bloats my LOC by at least a factor of 5, if not more.)

However, if I can provide a deliverable in the time allotted that satisfies the requirements stated and is 99.999% error-free, I have succeeded. If I cannot, I have failed.

Remember, you can't be 80% pregnant. Likewise, you can't be 80% productive. Either you produced or you didn't.

------
We are the carpenters and bricklayers of the Information Age.

The idea is a little like C++ templates, except not quite so brain-meltingly complicated. -- TheDamian, Exegesis 6

Please remember that I'm crufty and crochety. All opinions are purely mine and all code is untested, unless otherwise specified.