MostlyGeek

I love reading Joel’s blog. More often than not his posts lead me to learning something new. In fact, two of the books that I’m currently reading, The Secrets of Consulting: A Guide to Giving and Getting Advice Successfully and Measuring and Managing Performance in Organizations I found from Joel’s blog.

Today Joel posted a fairly heated (for his blog) post about measuring programming performance in organizations. Here’s an excerpt:

A management consultant at Bain wrote me a nice email, that included the following sentence:

“Our team is conducting a benchmarking effort to gather an outside-in view on development performance metrics and best practice approaches to issues of process and organization from companies involved in a variety of software development (and systems integration).”

I didn’t understand a thing he wrote. The email contained a lot of words (“benchmarking,” “outside in,” “performance metrics,” “best practice,” “process and organization”) each of which set off a loud buzzing alarm-like sound in my head. The noise from the buzzing was so loud and so distracting that I found myself completely unable to parse the email.

I think it was something about measuring performance in software organizations? aHA! YES! I know all about that. You can’t do that. Quit it. Stop it.

It’s true. You can’t, or at least you shouldn’t try to measure programmer performance. The reason being that whatever performance metrics you use people will naturally optimize themselves to excel in those metrics. However, there’s also the philosophy of, “if you can’t measure it, you can’t manage it”. I think both are equally valid and that good managers are the ones that are able to find the right balance.