Customer Reviews

Codermetrics: Analytics for Improving Software Teams

5 star:		(0)
4 star:		(4)
3 star:		(0)
2 star:		(0)
1 star:		(0)

 

 

This is a welcomed book to start a detailed conversion about metrics for software developers. The author presents an interesting dilemma: increases in computing power and advances in software industry made a thorough statistical analysis first possible and then indispensable for professional sport teams to succeed. Software industry itself lags behind in measuring what differentiates great software development teams and underperforming ones.

The book borrows heavily, if not exclusively, from sport related stats and presents their counterparts for software teams and team members. Endless sport references ensure stylistic consistency for the whole book and give it a sense of credibility, but they also quite distracting if you're not a sport buff. I also felt the sport analogies could be stretched only so far. There is one significant difference between a sport event and a software development cycle: delay between cause and effect. A goalie pulls across a crease to make an impossible save in an instant; an embarrassing give-away results in a goal in only 3 seconds. Software development is different. Distance between cause and effect may be as long as couple of months. A developer accumulates a lot of points during an iteration, and in doing so makes suboptimal decisions that only re-surface and hurt a project three month down the road. It's important to have metrics to account for these subtleties but the book doesn't address them at all.

"Codermetrics" recognizes that measuring performance of a team and its members cannot happen in a vacuum. The performance of the whole organization, losses and gains in a customer base, and analysis of competition, for instance, plays an important role in a more holistic measurement approach. At the same time, I didn't see the author emphasized strong enough how important it is to devise and include metrics for business analysts, managers, testers, system administrators and other team members to get to the more balanced picture. In any way, the author broke the silence and it's now up to other disciplines to contribute.

One of the most telling examples was a recollection by the author of all too familiar situation: two similar teams, two comparable projects, two opposite outcomes. It's easy to just contemplate and suggest theories on why one team failed and another succeeded. It's easy but not insightful. Looking at the metrics and spotting divergencies can tell a less biased and more thought-provoking story. Having metrics and comparing them one to one presents a concrete opportunity to learn, create new metrics and retire irrelevant ones. Without metrics it's nothing more but lamenting and getting lost in traps of one's own memory.

The biggest benefit of the book is a start of a detailed conversation with concrete examples of metrics and corresponding processes. Too many people in the industry are quick to point out difficulties and pitfalls of metrics but don't offer any actionable advice. I'm not a huge fan of modeling coder metrics against sport metrics, but I'm thankful to Jonathan Alexander for sharing his approach and experience.

I read this book for the past 2 days. Initially, I was thinking that there will be some measurement of developer contribution based on code metrics. But in that sense I was disappointed. However, the author does articulate how a measurement system can be setup and how they have actually used it.
There is a lot of value for agile teams and some insight he gives from practical experience (The magic triangle etc) were very useful to read.
If a team uses code metrics measurement system (Sonar for Java or TFS) along with this, then there can be significant improvement in management.
It is very thoughtful book. Well worth reading.

Codermetrics provides an interesting idea, measuring software development with a goal of trying to find things to improve. I found it interesting having seen bad metrics used and talked about in past. Codermetrics goes beyond the classically missed "LOC" (Lines of Code) metric that developers rightfully loath, and presents a variety of different metrics to measure. It bases the ideas around Sabermetrics, the analysis of baseball through metrics.

I found the ideas presented in the book interesting, and pretty well presented. While I can't see myself using them directly at the current point in time, I can see that measuring what is being doing can be useful for getting feedback, and helping to improve behaviours and techniques. The metrics presented in the book are interesting, and there are good ideas and tools for thinking about how to develop your own metrics, and refine those presented.

I'd recommend the book to people thinking about how to improve the performance of a software development team.

[This book was reviewed as a part of the O'Reilly Blogger Review Program]

"Codermetrics: Analytics for Improving Software Teams" by Jonathan Alexander is a must read for management to improvement their software teams and products. Alexanders takes an organic approach to walk the reader through metrics and processes accompanies by insights from his 30 years of career experience.

The first few chapters have heavy usage of sports statistics as software metrics analogies. While they are occasionally illustrative, I find them mostly a distraction, maybe because they are too long for me to focus on the original topic. The use of sports analogies reappeared in the set of metrics definitions, which may work if you can get the software team to think in terms of offense, defense, assists for ideas such as code quality, bug fixes and helping other developers.

It might help to skim the processes section as it answered many of my questions I had in reading the earlier sections. People factors, metric collection methods, and such are all mostly explained in the processes section. I'm still not convinced that all the metrics on individual developers will be effective since they ultimately "grade" the coder even though Alexander cautions against it. However, one of the gems of this book is that it asks questions about those metrics or analysis of them to make you think and hopefully customize them to help your software teams.

Overall it's a decent book, particular if you have yet to start collecting metrics