I picked a book called Codermetrics(book, website) yesterday - one of those impulse purchases because I liked what it said on the cover. I've not finished reading it completely, but I went through most of the meat of the book and its an interesting concept.
The core concept of the book is simple: Measure a developer - and by extension the development team and organization - in the same way the world measures sports persons, teams and organizations. The book's name is a play on Sabermetrics - which apparently is all the rage in Baseball these days as far as metrics go.
After a somewhat drawn-out beginning, the bulk of the book is focused on defining metrics for developers, teams/organizations and their combination. The developer metrics measure how good a developer (called coder throughout the book) is at advancing the team towards the org's goals (Offensive Impact); how good s/he is at preventing or avoiding the things that detract the team from the org's goals (Defensive Impact) and so forth. Specific attention is paid to work done beyond the call of duty (Pluses) and help given to others (Assists).
Next, the organization is defined in terms its successes (Wins), failures (Losses) and position relative to competitors. In each case, the end of the chapter gave some examples or archetypes that arise from specific combinations of the relative values that the metrics may take, for eg, what separates a junior coder from an architect, or what separates an enterprise company from a startup.
The final set of metrics - called Value metrics - were the most interesting. While the previous sets of metrics required some input data from the real world, these ones were derived from other metrics and were intent on exploring the contributions of individuals factored into the larger scheme of things in the organization. Terms like influence that a particular developer has on the team and company, the teamwork demonstrated etc become measurable things!
The final section of the book has some advise on how to go about implementing such a process in an organization.
Overall, the concept of the book and the simple language used to explain the concept is a win for the book; as is the author's repeated disclaimers that we should heed to his overall construct, not the specific metrics that he provides. This is sane advice and a welcome change from the typical prescriptive nature of texts on metrics.
I've started trying this out on one of my teams which is particularly feeling the pain of under-delivery. Highly recommended.
The core concept of the book is simple: Measure a developer - and by extension the development team and organization - in the same way the world measures sports persons, teams and organizations. The book's name is a play on Sabermetrics - which apparently is all the rage in Baseball these days as far as metrics go.
After a somewhat drawn-out beginning, the bulk of the book is focused on defining metrics for developers, teams/organizations and their combination. The developer metrics measure how good a developer (called coder throughout the book) is at advancing the team towards the org's goals (Offensive Impact); how good s/he is at preventing or avoiding the things that detract the team from the org's goals (Defensive Impact) and so forth. Specific attention is paid to work done beyond the call of duty (Pluses) and help given to others (Assists).
Next, the organization is defined in terms its successes (Wins), failures (Losses) and position relative to competitors. In each case, the end of the chapter gave some examples or archetypes that arise from specific combinations of the relative values that the metrics may take, for eg, what separates a junior coder from an architect, or what separates an enterprise company from a startup.
The final set of metrics - called Value metrics - were the most interesting. While the previous sets of metrics required some input data from the real world, these ones were derived from other metrics and were intent on exploring the contributions of individuals factored into the larger scheme of things in the organization. Terms like influence that a particular developer has on the team and company, the teamwork demonstrated etc become measurable things!
The final section of the book has some advise on how to go about implementing such a process in an organization.
Overall, the concept of the book and the simple language used to explain the concept is a win for the book; as is the author's repeated disclaimers that we should heed to his overall construct, not the specific metrics that he provides. This is sane advice and a welcome change from the typical prescriptive nature of texts on metrics.
I've started trying this out on one of my teams which is particularly feeling the pain of under-delivery. Highly recommended.
No comments:
Post a Comment