Q&A with author Adam Tornhill

Why did you decide to write this book?

I've spent much of my career trying to improve existing code, and I found it progressively harder as software systems and organizations keep growing in scale. Even though the software industry has improved dramatically over the two decades I've been part of it, we do keep repeating avoidable mistakes by isolating our influences to technical fields. I wrote this book to provide that missing link between technical and social sciences. This blend, behavioral code analysis, lets us prioritize technical debt based on the most likely return on investment, evaluate our software architecture based on how well it supports the work we do, bridge the gap between developers and business oriented people, and much more. My goal was to take mainstream software development one step closer to a point where decisions -- both technical and organizational -- are influenced by data and research from multiple fields. I'm really, really happy with the end result and hope you'll enjoy it too.

What kind of experience would help readers get the most out of this book?

To get the most out of this book you should be an experienced programmer, technical lead, or software architect. The most important thing is that you have worked on larger software projects and experienced the various pains and problems. You don't have to be a programming expert, but you should be comfortable looking at smaller code samples. Most of the discussions are on a conceptual level and since the analyses are technology-neutral, the book will apply no matter what programming language you work with.

What do you hope readers take away from this book?

The key point in the book is to base decisions on data by putting numbers on our gut feelings. Software development, and in particular the people side of it, is notoriously hard to get right. By embracing behavioral code analysis we get to tap into the social side of code and start to measure things that we cannot deduce from the code alone, like communication and coordination needs, Conway's Law, and long-term complexity trends. I also want to point out that behavioral code analysis doesn't offer any silver bullets, nor does it intend to replace anything. Instead the techniques in this book are here to complement your existing expertise by focusing your attention on the parts of the system that need it the most.

How does this book compare to 'Your Code As A Crime Scene'?

Software Design X-Rays represents the evolution of the ideas from my previous book, Your Code As A Crime Scene. If you read the previous book, you're already familiar with hotspots and some of the change coupling metrics presented in chapters 2 and 3. These two concepts lay the foundation for the more advanced analyses, and the new book goes deeper into both areas. Most of the material points out new directions that I haven't covered before. Software Design X-Rays is of course also interdisciplinary and blends software engineering with psychology, but this time there are no direct forensic references.

What's your favorite part of the book?

I like chapter 4 on refactoring patterns since it makes the technical debt detection techniques actionable by providing specific recommendations. I also enjoyed writing chapter 7, Beyond Conway's Law, that brings some valuable findings from group psychology into the software field. Those findings fill out the missing pieces in Conway's Law and helps guide your organization towards better code. Finally, I have to mention the last chapter which explores preventive and predictive uses of behavioral code analysis. I like that chapter because the resulting information becomes like an extra team member that points out areas of the code in need of our attention as we code along.