I once worked on a project with severe problems in its database access. Changes were awkward, they took longer than they should, and bugs swarmed like mosquitoes at a Swedish barbecue.
Learning from mistakes is important, so I decided to redesign the worst parts of the database layer. Something interesting happened. Even though the database layer was in better shape, developers still complained about how fragile and unstable it was. Changes still broke unrelated features. What went wrong? Did I mess up?
While the database improved, it turned out that wasn’t where the true problems were. The database was just the messenger subtly warning us about temporal coupling (and we shot the messenger).
Other parts of the system unexpectedly depended on the data storage. The true problem was in automatic system tests. A minor change to the data format triggered a cascade of changes to the test scripts. This wasn’t obvious because the scripts didn’t explicitly call the database code.
After reading the previous chapter, you now can see how a temporal coupling analysis could’ve helped us find this problem earlier. Redesigns are about minimizing risk and prioritizing areas of code that have the largest impact on the work we’re doing now. Get it wrong like we did, and you will miss an opportunity to make genuine improvements to your code. Let’s see how we can use temporal coupling to avoid these mistakes.