Adam Tornhill

I often wish there were a better publication format for things that are worth more than some blog posts but don't have a whole book's worth of content. This book would have made a great booklet, but did feel padded.

That said, the techniques were useful. The book, at it's core, is about using data in the source code repository to get a broader understanding of a code base. The techniques are described in some detail, but the book leaned a bit heavily on a particular tool (Code Maat). I would have appreciated high level pseudocode versions of the various analysis techniques.

Throughout the book, we looked at several properties, all of which can be extracted from many source control repositories:
* change frequency
* lines of code -- the simplest proxy for complexity
* code churn (lines changed over time, rather than raw revisions)
* temporal coupling between code (files that are frequently changed together)
* authorship for expertise and churn (many authors)
* joint authorship to determine the social landscape of a project

The author also describes a number of interesting visualization methods and points to libraries that can generate them once you've extracted the raw data.

Note that Tornhill frequently warns that these are only heuristics. Although the framing around "forensic techniques" was rather thin, one important way that these tools are similar to tools of crime investigation is that they won't give you answers on their own. They will, however, point you at areas that warrant further investigation.… (mais)

Some software projects start from scratch, are very limited scope, you work on them with a very small team for a few months or a year, and then move on to another project. This book is not for people working in such conditions. On the other hand, if you find yourself dealing with software-based products comprised of million line code bases that have been developed by tens of engineers spread throughout the world during many years, and you're supposed to fix bugs, and add new features, thinking about how you can even begin to understand the huge complexity, well, then, this book will mean something to you.

The book's beauty stems from the fact that software engineers can always do better, and that it is crucial to utilize the metadata surrounding the software development process, both statically, as well as temporally. Once you internalize this mindset, and start to look at the systems at a high level, you realize that there's still a lot of work to be done to enhance the practice of software development.

One of the good aspects of the book is that the analyses described by the author are mostly independent of programming languages and paradigms: the code repositories analyzed range from C# projects to the ones in Java, Scala, and Clojure. Therefore, you can make use of the book if you work with object oriented technologies, or are a functional programming aficionado. Another good point: the examined source code repositories are high profile open source projects such as Hibernate, and Scala. This means you can easily perform similar analyses yourself on the most recent version of those projects, and since they are popular ones, you either know about them, or used them heavily in your projects.

If I had to summarize the book, I'd say the gist of it is: find the hotspots in your project, check if they are problematic, and focus on temporal coupling for proactive handling of complexity that is to reveal itself soon. The author starts from these simple premises, and proceed to show how they can be applied in detail to many different code bases, using the tools he developed and applied to the revision control system data such as Git logs. The set of analyses that can be done, and the insights that straightforward visualizations can lead to are impressive!

You might have noticed that I didn't touch on the author's use of concepts from criminal psychology: that's because I think contrary to what the title might imply, this book is much more about the scientific analysis of software product and process artifacts in the service of higher quality engineering, rather than analyzing sofware from the perspective of criminal psychology. Of course, the author's background in psychology and cognitive science, in addition to his engineering experience, is the reason this book is probably in a category of its own, but still, most of the anecdotes, even though interesting in themselves, can be considered tangential to the main topics of the book.

The book finishes by noting this is not the end of the story, showing we need more tools to utilize the metadata such as building code recommenders by doing statistical analysis on your code base (and I'd add even other code bases!), integrating dynamic information about the code, utilizing even more detailed data such as in-commit changes that your development tools can record, and other advanced features to be implemented as concrete technologies. Some of them, such as code recommenders already started to appear in the last few years (see http://www.eclipse.org/recommenders/), but we need more of them, as well as cross-platform ones.

I can recommend this book experienced software engineers working on long-term, complex software projects and products, as well as engineering-oriented managers who seriously consider to enhance their processes.… (mais)