Measuring Programmers' Productivity. Bad, good or invasive?

Question

A client needs my company to develop an app that will be able to measure the programmer productivity, by getting information from VS, IE, SSMS, profiler and VMware.

For example:

1. Lines, Methods, Classes (Added, Deleted, Modified)
2. How many time spent in certain file, class, method, specific task, etc.
3. How many time in different stages of the development cycle (Design, Coding, Debugging, Compiling, Testing)
4. Real lines of code.
5. Etc

They told me they want to implement PSP.

What are the advantages and disadvantages of such an approach?

Answer 1

Trying to measure coder productivity with any of these metrics is almost a waste of time. If metrics like these are the criteria, then any humans will tend to game the system.

You want me to write more lines of code? I will write more lines of code. You may not like what those lines do, though.

You want me to fix more bugs? I will fix more bugs, but they'll be the easy bugs. No one will touch the hard bugs, if they each take six weeks to fix but only give credit for one bug fixed.

I'm not saying anyone would be uncooperative or anything -- far from it. Just that people want to do a good job, and if the definition of a good job is to meet certain metrics, then they will do their best to meet those metrics.

Joel Spolsky included an article about this topic in one of his books. Here it is:

Larry's rules of software engineering #2: Measuring testers by test metrics doesn't. by Larry Osterman, April 2004.

Would I quit a job at such a company? I like to finish what I start, so I would not quit immediately. However, I would ignore their arbitrary metrics, and work with a level of quality that I feel is appropriate. I like to do a good job, and generally my managers have been happy with my work, without using a lot of metrics.

Answer 2

string line = @"something
    i 
    might
    be
    tempted
    to 
    do
    if 
    i
    was
    evaluated
    by
    lines
    of
    code.";

Answer 3

If those are the productivity criteria, then the client has little idea what software developers really do.

Software productivity is only marginally associated with lines of code or the like. It's about creating useful, high-quality abstractions that result in effective solutions and maintainable code over the long run. It's about delivering key, well-implemented features in a timely fashion while recognizing what can be cut/reduced if time/resource constraints force compromises. All of that requires thought and good decision-making, which is measured by end results not by keystrokes or any other criteria involving direct interaction with a computer, source files, etc.

A company management that views productivity the way you describe has little idea what software is really about, and it would be difficult to see what merit there would be in remaining in such a culture for any programmer with self-respect and a desire for professional growth.