Table of Contents for

Your Code as a Crime Scene

Take It Step by Step

The dependencies between organizational aspects and system design are complex. As a consequence, the analysis in this chapter contains multiple steps. Let’s recap them:

Using the steps above, you’re now able to perform a basic analysis of communication problems and team productivity bottlenecks. When you find them, you need to react. Unfortunately, that’s the hard part because it depends on your specific organization and system.

One typical action is to rearrange the teams according to communication needs. Because those needs will change over the course of a longer project, you probably need to revisit these topics at regular intervals. Done right, such a rebalancing of project teams has been found to minimize communication overhead. (See The Effect of Communication Overhead on Software Maintenance Project Staffing [DHAQ07].)

This is what happened on the project I told you about at the beginning of the chapter. The project was supposed to deliver in three months. After one year of expensive and intense parallel development, the project was put on hold and analyzed, and the teams were reorganized. After that, we had fewer developers working on the code, and yet you won’t be surprised to learn that we got a productivity boost that lasted.

Sometimes it’s easier—and indeed more appropriate—to redesign the shared parts of the system to be more inline with the structure of the organization. This alternative is close to what Conway himself suggests in his classic paper as he concludes that “a design effort should be organized according to the need for communication” (source: How do committees invent? [Con68]). The techniques in this chapter are there to help you with this challenging task.

Toward a Communication Map

In this chapter, you learned that the number of authors behind a module correlates to the number of post-release defects in that code. We discussed how this is a consequence of the increased communication overhead that comes with parallel work. You also learned to investigate it yourself through an authors analysis.

We then looked at Conway’s law and how the way we organize our work impacts the code. You learned that your project organizations must align with the way the system is structured. You also got the basic tools to perform that analysis. During these analyses, we found a way to identify how much each developer has contributed in terms of code. We used this metric as a crude device to find the main developers.

With the analyses in this chapter, you’ll be able to spot many organizational problems that creep into your code. But we can do even better. In the next chapter, we’ll look at individual developer patterns. As you’ll see, those patterns make good predictors of defects. As a bonus, you’ll learn to build a complete knowledge map of your system. It’s a map that helps you plan, communicate, and estimate knowledge loss in case a core developer leaves. Let’s move on!