Table of Contents for

Your Code as a Crime Scene

How to Read This Book

This book is meant to be read from start to finish. Later parts build on techniques that I introduce gradually over the course of several chapters. Let’s look at the big picture.

Part I Shows How You Detect Problematic Code

In Part I, you’ll learn techniques to identify complex code that you also need to work with often. No matter how much we enjoy our work, when it comes to commercial products, time and money always matter. In this part, you’ll learn methods to identify and prioritize the changes to the code that give you the most value.

We’ll build the techniques on forensic methods used to predict and track down serial offenders. You’ll see that each crime forms part of a larger pattern. Similarly, each change we make to our software leaves a trace. Each such trace is a clue to understanding the system we’re building.

These modification patterns let you look beyond the current structure of the code to find out where it came from and how it evolved. By mining commit data and analyzing the history of your code, you learn to predict the code’s future. This will allow you to start the fixes ahead of time.

Part II Shows How You Can Improve Your Architecture

Once you know how to identify offending code in your system, you’ll want to look at the bigger picture. You’ll want to ensure that the high-level design of your system supports the evolution of your code.

In this part, we’ll take inspiration from eyewitness testimonies to see how memory biases can frame both innocent bystanders and code. You’ll then learn techniques to reduce memory biases and see how you can interview your own codebase. Your reward is information that you cannot deduce from the code alone.

After you’ve finished Part II, you’ll know how to evaluate your software architecture against the modifications you make to your code. You’ll also have techniques that let you identify signs of structural decay and expensive duplications of knowledge. In addition, you’ll see how they provide you with refactoring directions and suggest new modular boundaries in your design.

Part III Shows How Your Organization Affects Your Code

Today’s large software systems are developed by multiple teams. That intersection between people and code is an often overlooked aspect of software development. When there’s a misalignment between how you’re organized versus the work style your software architecture supports, code quality and communication suffers. As a result, we wind up with tricky workarounds and compromises to the design.

In Part III, you’ll learn techniques to identify organizational problems that show up in your code. You’ll see how to predict bugs from the way we work, understand how social biases influence software development, and uncover the distribution of knowledge among developers. As a bonus, you’ll learn about group decisions, communication, false serial killers, and how they all relate to software development.

Because we base these techniques on version-control data as well, the methods are aligned with how you really work, instead of to any formal organizational chart. As you’ll see, those two views often differ.