Chapter 11
Norms, Groups, and False Serial Killers

Part II showed you how to analyze high-level designs and architectures. We based the techniques on the concept of temporal coupling. You learned to use temporal coupling to evaluate how well your software architecture supports the modifications you make to the code.

We also discussed how you can use that information to detect structural decay, supervise test-automation efforts, and guide your design discussions. You also saw how the hotspot analyses from Part I complement your new forensic code skills. As far as technology goes, you’re set with what you need to uncover the mysteries of your codebase.

But large-scale software projects are more than technical problems. Software development is also a social activity. Programming involves social interactions with our peers, customers, and managers. Those interactions range from individual conversations to important decisions made in large groups.

Just as you want to ensure that your software architecture supports the way you evolve your system, you also want to ensure that the way you organize your work aligns with how the system is structured.

How well you and your team fare on these social aspects influences how your system looks. That’s why social psychology is just as important to master as any programming language. In this final part of the book, you’ll learn about social biases, how you can predict bugs from the way we work, and how to build a knowledge map of your codebase. And just as before, we’ll mine supporting data from our version-control systems.

We’ll start with the social biases. These biases may lead to disastrous decisions, which is why you want to be aware of them and recognize them. We’ll then to see how we gather objective data on the social aspects of software development to inform our decisions about team organization, responsibilities, and our process. Let’s start in the middle of a criminal investigation.