Chapter 7
Treat Your Code As a Cooperative Witness

In Part I, we looked at how to detect hotspots in code. You learned to pass quick judgments on the hotspots you found. You also learned how to measure their complexity trends to determine whether the code was improving or getting worse over time. This is the ideal starting point. The next step is to look at the bigger picture.

In this part of the book, we’ll transition from looking at individual modules to analyzing complete software architectures. We’ll evaluate how well the high-level design of our system supports the evolution of our code: is our architecture more of a hindrance than a help?

We’ll still use hotspots, though. The techniques you’re about to learn identify high-level structural problems, and we’ll use hotspots to gain more information.

We’ll start with another forensic psychology case study to learn about eyewitness interviews. This case study illustrates common memory biases and why we need to support our decisions with objective data. We’ll then apply the concept to software development. You’ll see how a change to one component leads to a cascade of complex changes in other parts of the code. Hotspots rarely walk alone.

This leads us to the concept of temporal coupling. Temporal coupling is a type of dependency you cannot deduce just by looking at the code. It’s a powerful interview tool for our codebase and lets us identify improvements based on how we worked with the code in the past.

So let’s move ahead and listen to the modification patterns in our system. They have a lot to tell us.