[phkahler]

Metrics are very hard to apply to engineering, and software development in particular. This has been shown many times. Metrics became all the rage with statistical process control, where you monitor production of widgets. The problem is that engineering is by definition not creating the same thing over and over again - if you think it is, go use Excel to send email, and word for web browsing. There are lots of similar things among different pieces of code, and hence design patterns. But good metrics have proven difficult. Lines of code produced turns out to cause people to add redundant comments, and if you exclude comments it causes other things. Closed bugs/issues is better, but to be really effective you need to identify how new bugs are introduced. Some people create as many as they close and that would look good if you monitor closures. Other things have been tried with varying success. The core problem is that engineering is not a well defined process and never will be.

Another way to look at is this: none of the marketing metrics he mentions have anything to do with peoples performance. Click rates are a measure of the effectiveness of a marketing strategy, not necessarily the effectiveness of a person in marketing. You use that data to drive decisions about how much to spend on different marketing activities. The equivalent for engineering is to determine how much to spend on each developer. In other words, who to keep and whom to fire, and that shouldn't be a really dynamic process. Even if you had good metrics on development, what knob are you going to turn to cause a change in those metrics?