The problem I have with Fowler, Beck, et al isn't really with what they've said per se, but people conflate "you can't measure individual developer performance " (and honestly I often think you can't even measure the team performance unless "team" encompasses a LOT of folks) with "you can't EVALUATE individual developer performance", and they get mad when someone tries to hold developers accountable for what they do and how they do it.

So yeah, sitting there trying to get these Taylor-esque "time on task", velocity, bug counts, LOCs per hour, blah blah blah "measurements" absolutely bogus. But "I've asked you to write this kind of code in this fashion because it performs better and is more secure four times in the last month, but you insist on doing it the wrong way" is totally valid.

And that's the REAL problem with so-called "leadership" and "management" in this industry. A bunch of the folks came from a technical background and don't have the actual experience leading & managing to have those hard conversations past some blance "coaching", and most of the rest don't have the technical know-how to *know* that the conversation needs to be had in the first place. So they look for a "perfect metric", either so they can declaim the moral responsibility for that conversation ("the sytem is telling me that you're a low performer") or not require the exprience for that conversation.

A big reason the tech companies are flattening their orgs and shedding managers is because they think (for a lot of good reasons) that technical management is mostly useless middlemen shuffling papers and status reports. But in large part that is because they put people in these management positions who were not well suited for them, and then didn't give them the training, knowledge, support, etc. necessary to be effective.

J.Ja