Law enforcement improved their interview processes. We use similar techniques: avoid leading questions, play back tape-recorded conversations, and compare interview information with other information. We just do it with code and not people.

A temporal coupling analysis complements but does not replace your expertise. This analysis is great for large codebases with multiple developers. I once analyzed a large project that I was involved with and found several unexpected cases of hidden dependencies. These dependencies had been costing time and effort as well as introducing bugs. Once they were uncovered, we redesigned the project.
It’s also a technique I’ve found useful in my own private projects. The analysis gives me a different view into the design and reveals things I missed.
It’s also a helpful tool when considering design changes. By analyzing historical change patterns, we get an idea of how deep and far-reaching our proposed change will go.
If we look into the research on temporal coupling (or its synonyms, change coupling and logical coupling), we find several applications:
One research team used visualization techniques to compare coupled modules against the specified software architecture. This allowed them to identify signs of structural decay (see Animated Visualization of Software History using Evolution Storyboards [BH06]).
Another research team used temporal coupling as a code-recommendation guide. Using the results of such an analysis, they could recommend relevant source code for specific modification tasks (see Predicting source code changes by mining change history [YMNC04]).
A study of an object-oriented system used temporal coupling to detect architectural weaknesses, such as poorly designed inheritance hierarchies (see CVS release history data for detecting logical couplings [GK03]).
In the chapters to come, you’ll learn about these applications. The idea is that it’s just impossible to keep track of everything that’s happening in a codebase under heavy development. In a temporal coupling analysis, we have a tool that lets us monitor and react to costly problems early.
Now, let me show you how temporal coupling looks. You’ll get a high-level view of the concept, which makes it easier to apply in practice later.
It’s difficult to show temporal coupling with a single illustration. What would be best is video. Despite the advances in ebook technology, we’re not quite there, so bear with me as I walk you through the following images.

I replayed version-control data and animated the growing system to illustrate how Code Maat evolved. Each time a module changed, the size of its building grew a little. Tall buildings in the illustration have high change frequencies. To make it easier to spot patterns, I increased the opacity of the building’s color every time it changed. As the hotspot cooled down, I decreased the opacity.
Looking long enough at this animation could drive you crazy, but you would spot some patterns. In the following figure, I highlight two patterns showing how modules are changing.

Explicit coupling: git.clj and git_test.clj tend to change together. This is hardly surprising since the latter is a unit test on the former. In fact, we’d be surprised if the pattern wasn’t there. A unit test always has a strong degree of direct coupling to the code under testing.
Temporal coupling: The right-hand snapshot is more interesting: core.clj and svn.clj change together. It’s interesting because there isn’t any explicit dependency between them. You have to dig into the source code to figure out they are related. Congratulations, you’ve just detected a case of temporal coupling in Code Maat.
Temporal coupling can point to either expected co-changes, such as a module and its unit tests, or serious problems in design. Let’s see what they are.
Temporal coupling is a powerful interview tool for your codebase. It lets you identify design issues you cannot spot in the code alone. Once you’ve found them, the reasons behind the temporal coupling often suggest places to refactor, too:
Copy-paste: The most common case of temporal coupling is copy-paste code. This one is straightforward to address; extract and encapsulate the common functionality.
Inadequate encapsulation: Temporal coupling is related to encapsulation and cohesion. In the next chapter, you’ll see temporal coupling that was the result of not isolating program arguments from application logic. Encapsulating the concept that varies would improve the design.
Producer-consumer: Finally, temporal coupling may reflect different roles, such as a producer and consumer of specific information. In that case it’s not obvious what to do, and it might not be a good idea to change the structure. In situations like this, we rely on our expertise to make an informed decision.
Findings like these are the main strengths of a temporal coupling analysis. They give us objective data on how our changes interact with the codebase and suggest new modular boundaries.
As we move on to perform an analysis in the next chapter, we’ll see further refactoring support: a temporal coupling analysis also shows how severe and deep the necessary changes will go. This guides our design and reasoning upfront, too.