Your Code Is Still a Crime Scene

My previous book, Your Code as a Crime Scene [Tor15], introduced concepts from forensic psychology as a means to understand the evolution of large-scale codebases. Forensics was a metaphor drawn from where it all started. Years ago I did a geographical offender profile on a series of burglaries in my hometown, Malmö, Sweden.^[138] Such offender profiles look for patterns in the distribution of connected crime scenes, which are then used to focus investigations on the areas of interest. These forensic hotspots, as shown in the figure, are all about probabilities, just like the hotspots we detect in code.

At the same time I worked full-time as a software consultant on a project plagued by technical debt, and noted the parallels to forensics. Of course, I don’t mean to imply that developers are burglars—save some clock cycles every now and then—but geographical offender profiling is about prioritizing based on human behavior and how humans interact with their environment. The environment of developers is code, and all their past behavior is preserved in version control, so what if we could uncover patterns in that behavior? The book you’re reading right now descends directly from that thought.

However, a metaphor can only be stretched so far, and I didn’t want the metaphor to distract from the real-world use cases of behavioral code analysis. Hence, the current book is void of forensics.

But I had a second reason for using the crime scene metaphor, and that reason remains important. Modern forensic psychology has evolved to use mathematical statistics as a tool to support actions and decisions. And here the software industry has a lot to learn, as far too many fateful technical and organizational decisions are based on little more than gut feelings, opinions, and the occasional biased group discussion.

The software industry has improved dramatically during the two decades I’ve been part of it, and there’s no sign it will stop. But it’s also an industry that keeps repeating avoidable mistakes by isolating its influences to technical fields. Large-scale software development has as much in common with the social sciences as with any engineering discipline. This means we could benefit from tapping into the vast body of research that social psychologists have produced over the past decades.

One of the implied goals of this book is to take mainstream software development one step closer to a point where decisions—both technical and organizational—are influenced by data and research from other fields. There are a lot of things we actually know about software development, and we’ve seen some of the studies behind that body of knowledge throughout this book. Some of the resulting findings and recommendations may well be controversial, and there’s still a lot to discover and learn.

Behavioral code analysis doesn’t offer any silver bullets, nor does it intend to replace anything. Instead the analyses are here to complement your existing expertise by focusing your attention on the parts of the system that need it the most. The ultimate goal is all about writing better software that’s able to evolve with the pressure of new features, novel usages, and changed organizational circumstances. Writing code of that quality will never be easy, as software development is one of the hardest things we humans can put our brains to. We need all the support we can get, and I hope that Software Design X-Rays has inspired you to dive deeper into this fascinating field.