In Your Code as a Crime Scene, Adam Tornhill asks developers to walk into a codebase the way a detective walks into a crime scene: examine the clues, trace the patterns, and find what's behind the problems that slow the team down. Instead of focusing on writing new code, he analyzes the history and behavior of existing code to find where the problems are and why they exist.
Code has a history
A codebase changes over time, shaped by team decisions, deadlines, and changing requirements. To understand it, you need to know how the code got to its current state, not only what it looks like today.
Tornhill digs into that history: which parts were modified most often, and where the bugs cluster. Those are the “hotspots”, the areas most likely to cause problems in the future. They often carry technical debt and drag productivity down if nobody deals with them. Instead of rewriting or refactoring everything, Tornhill suggests focusing on the code you and your team touch most often.
Maintenance is most of the job
Most developers think their main job is writing new code. Tornhill argues that maintenance (understanding, analyzing, and improving existing code) is the bigger part of the work. It's the longest phase of the lifecycle: once a feature is written, it lives for years and needs updates, bug fixes, and changes for new requirements.
So he asks us to write code with its future readers in mind, including our future selves. Thinking long-term while we write reduces technical debt as we go.
Hotspots and change patterns
Tornhill's main contribution is a data-driven way to find hotspots: areas modified many times over short periods, which often means something is wrong. Improving those has a much larger effect on stability than working on code that rarely changes.
This gives developers a way to prioritize technical debt. Instead of rewriting code because it feels messy, you pick targets from its change history and real-world usage.
The people behind the code
The book also covers the human side of software development. Software is a social activity, and the way developers work together explains a lot about why parts of a system look the way they do. Code written under tight deadlines looks different from code written with time for testing and refactoring.
Tornhill recommends looking at the team's workflows, communication patterns, and even stress levels. They help you predict where shortcuts were taken and where future issues are likely to show up. You analyze the code and also the context it was written in.
Beyond static analysis
Static analysis only shows the code as it is right now, which can hide the areas that change often or break often. To find the real problems you need the full lifecycle of the code: how it evolved, who touched it, and how often it changed.
Tracking change frequency and where developers spend their time shows patterns a static code review can't. You then use them to decide what to fix first.
What I took from it
The book gives a practical, data-driven way to manage technical debt in large codebases. My main takeaway is to prioritize improvements based on where you and your team spend the most time, let the data make the call, and remember that code is a product of both technical and social processes.