The only useful measures of productivity in any field are:

1. Tasks done correctly per unit of time
2. Money earned vs. money cost

Essentially, how quickly does the worker do correct work and how much profit are you making on that worker's cost. Now, "profit" is a term that only the business people can define. For example, IBM has about a thousand people working in various research labs on products that won't see market, let alone turn a profit, in 30 years (if ever). But, the business folk at IBM have 70 years of being able to point to products that have come out of IBM research that have paid for said researchers 100 times over. Google's policy of 20% time is very similar.

You seem to be more interested in the first measure - correctly finished tasks per unit of time. In programming, there is a corollary measurement that I allude to in my sig - the difficultly of changing a worker's product. If you produce code that works perfectly twice as fast, but it takes 10x longer to make a change, you have cost the company more money in maintenance that you saved in production. And, given that most applications spend 80% of their life cycle in maintenance, this can be a very significant criterion.

And, then there's the more ephemeral stuff. Let's say we have a team member who doesn't produce a lot of code and what they do produce isn't very good. But, they have a very good understanding of the application's architecture and have been instrumental in avoiding a number of pitfalls. What value does that person bring to the team? Personally, I like having people like that on board. But, how do you measure "pitfalls avoided through lunch discussions"?

Ultimately, it boils down to the fact that programming isn't engineering - it's sculpting or music composition. While you can have production quotas in the arts¹, that leads to a very stagnant output with little innovation. And we can see this in our field. Take a look at the innovators of programming theory and how they tend to work. Then, look at the corporate drones and how they tend to work.

Putting metrics on programming output isn't a bad thing. But, it's not clear how one measures maintainability, code quality (not kwalitee), and various other "unmeasurables." And, frankly, code coverage is probably more important than the number of tests. I may only need 30 tests to cover these 600 lines of code, but I may need 600 tests to cover these 30 lines over here. The rest of your proposed metrics fall into the same category. ("number of lines made reusable" - that's called refactoring and it's something everyone should do on a continuous basis!)

As for "average time to fix" ... that kind of metric scares the bejeezus out of me. It assumes that your programmers are slackers who only intend on mooching off the company. Bugs will take however long they take to find. Fixing a bug is almost always very quick, once you've isolated the problem and generated a repeatable testcase. Managers who say "This bug has been open for 3 weeks. Fix it already!" don't understand that creating a repeatable testcase can take 99% of time to actually fix a bug.

1. The cathedral choirmasters in the Middle Ages were required to write a new piece of music every Sunday and every feastday.

---

---

• Are you posting in the right place? Check out Where do I post X? to know for sure.
• Posts may use any of the Perl Monks Approved HTML tags. Currently these include the following:

  <code> <a> <b> <big> <blockquote> <br /> <dd> <dl> <dt> <em> <font> <h1> <h2> <h3> <h4> <h5> <h6> <hr /> <i> <li> <nbsp> <ol> <p> <small> <strike> <strong> <sub> <sup> <table> <td> <th> <tr> <tt> <u> <ul>

• Snippets of code should be wrapped in <code> tags not <pre> tags. In fact, <pre> tags should generally be avoided. If they must be used, extreme care should be taken to ensure that their contents do not have long lines (<70 chars), in order to prevent horizontal scrolling (and possible janitor intervention).
• Want more info? How to link or How to display code and escape characters are good places to start.