Table of Contents for

Your Code as a Crime Scene

Let Your Questions Guide Your Analysis

The techniques in this book came about because we needed to understand large software systems. Because, let’s face it, software development is hard—we programmers need all the help we can get. Our collection of analysis and heuristics provides such support. We just need to apply it wisely. Let’s discuss how.

Start Simple and Then Elaborate as Needed

The hotspot analysis from Part I is as close as we get to a silver bullet. Sure, you’ve learned about the limitations of hotspots; you’ve seen false positives and biased data. Yet a hotspot analysis often manages to provide you with a high-level view of the codebase’s condition. A hotspot analysis is an ideal first step.

In addition to hotspot analysis, I always check temporal coupling. Start with an analysis of individual modules, as we did back in Chapter 8, ​Detect Architectural Decay​. Look for surprising modification patterns and patterns that cross architectural boundaries.

If you know the codebase well, I also recommend that you specify its architecturally significant boundaries in a transformation file and perform an analysis on that level, as we did in Chapter 10, ​Use Beauty as a Guiding Principle​.

When you need more supporting data, either to understand the problems or to prioritize improvements, look to supplement your results with the code churn measures we learned about in Chapter 14, ​Dive Deeper with Code Churn​.

Finally, you need to consider the social environment where your system evolves. Let’s recap that part.

Support Collaboration

We started Part III with an overview of how we work in groups. You learned about social biases and saw how they can turn group decisions into disasters. These biases are hard to avoid, and you should keep in mind that we need to challenge them, as we saw in ​Challenge with Questions and Data​.

In small organizations, we all know each other and how we work. But as soon as an organization grows, even for a group of seven to ten people, things change for the worse, and you need communication aids. The knowledge map that we discussed in Chapter 13, ​Build a Knowledge Map of Your System​, is a powerful concept to guide you in such settings.

If you work with multiple teams, I recommend that you keep track of parallel work in your codebase. As you learned in Chapter 12, ​Discover Organizational Metrics in Your Codebase​, parallel work leads to lower-quality code and more defects. When you identify modules that suffer from parallel work, you investigate them further with fractal figures, as we did in ​Visualize Developer Effort with Fractal Figures​.

Changing the way you work will never be easy. The techniques in this book can only help you make more informed decisions that let you move closer to your team’s potential productivity.

There’s much more to be said about the social influences on software design. For example, we haven’t talked much about how our physical workplace affects our ability to code.

Joe asks:

Great, So How Does the Physical Workplace Affect Our Ability to Code?

Our office space is an important determiner of job performance. As Peopleware: Productive Projects and Teams [DL99] reports, individuals in quiet working conditions are one-third more likely to deliver zero-defect work than their peers in noisy environments. And it gets worse with increased levels of noise.

Studies like this should be an alarming message to any company that depends upon the creativity and problem-solving skills of its employees. In reality, our office environment is often neglected. Many programmers, myself included, fall back on earphones and music to shield us from the noise. It’s important to understand the tradeoffs here: when we choose a soundtrack to our code, the effect varies with the task.

Music is an excellent choice when you need a distraction to help you get through a repetitive, routine task. It may get you to perform slightly better and may make the task more enjoyable in the process. On the other hand, music will hurt your performance when working on novel and cognitively demanding tasks, which include programming. However, a noisy work environment is even worse. If you have to code under noisy conditions, music is a decent alternative. Just remember to select music with the following qualities:

1. Avoid music that affects you emotionally. Choose something that you neither strongly like nor strongly dislike.

2. Avoid music with lyrics, because words will compete with the code for your attention.

3. Pick white noise if you prefer it over music. White noise works well as a noise-cancellation technique, but just like music, it cannot compete with quiet working conditions.