The next book on my review list is Your Code as a Crime Scene. The book describes forensic techniques for detecting problems like defects, bottleneck and design. To be more specific, these techniques identify problems by looking at the source code and how it changed over time. The author draws parallels with criminal forensics by treating code as “evidence” and problems as “culprits”. For me, this is an exciting and new approach - I haven’t seen it described anywhere before. It’s particularly attractive because you can apply it to unfamiliar projects as well as your own ones and gain previously unseen insights. As a bonus, you get some pretty intriguing anecdotes from real-world criminal forensics, making a very engaging read.

By looking into the history of your system, you’ll learn to predict the future. This will allow you to act on time, should there be any signs of trouble.

The book consists of three parts, with each part including several chapters. The first part of the book focus on exploring the code, introducing the CodeCity project. Even with visualization aids, there is often too much code to look at, so the book introduces the concept of hotspots: code that changes frequently. Since code changes for a reason, code that changed frequently in the past is likely to change again in the future, and deserves extra attention. When examining a hotspot, it’s worth looking for code that is particularly complex code, where complexity can be measured by either the number SLOC or, interestingly, properties of the source code indentation. Another sign of trouble includes poor naming. Where there is an overlap in symptoms — poorly named, complex code changing frequently — represents a red flag.

We should treat architecture as a set of principles rather than as a specific collection of modules.

The second part moves to a higher abstraction layer and looks at architectural issues. It introduces the novel concept of temporal coupling — code that changes frequently together — to search for hints why code changed. This method is great for finding hidden dependencies, a sign of architectural decay. Measuring temporal coupling enables you to drive design and refactoring decisions with data as opposed to intuition. These measurements can be automated to give your architecture a sort of “safety net”: if things go pear-shaped, you’ll know earlier rather than later. This idea resonates well with the fitness functions described in Building Evolutionary Architectures.

The third and final part focuses on the social aspects of code. For example, when joining a new team, it’s worth knowing who’s familiar with which parts of the code. You learn about interesting concepts like process loss and pluralistic ignorance, Conway’s Law, and code churn. The last of these is particularly helpful to identifying problem areas, because it exposes parts of the code that changed extremely rapidly and are therefore more likely to have cut some corners.

To summarize, the techniques described in this book are a worthy addition to your software engineering toolbox. I look forward to applying them in my own projects.