It’s easy to look at code and think that there is nothing more than what we see. When we look at it, we see operators, identifiers, and other language structure, but that is all surface. We forget the depth. We spend so much time looking at the current state of the code that we forget its history and all of the forces that influenced it along its path toward the present.
We pay for this myopia. Many code changes are incredibly shortsighted, both in terms of our vision of what the code will be in the future, and the way that it got to be the way that it is.
Years ago, I was struck by the fact that we use version-control systems to keep track of our projects’ histories, but we hardly ever revert to previous versions. Those versions exist as an insurance policy, and we’re lucky when we never have to file a claim. It’s easy, then, to look at that record of changes and see it as waste. Do we really need more than the last few versions? The naive answer is no, but we have a real opportunity when we enthusiastically say yes—we can mine our source code history to learn more about us, our environment, and how we work. That information is real power.
I think that we are at the beginning of a new era of awareness about how software changes. We’re abandoning the static view of code and seeing it as a verb—a constantly changing medium that reacts to its immediate and extended environment. Your Code as a Crime Scene is the first book I’ve encountered that takes that view and runs with it. Adam presents tools, techniques, and insight that will change the way you develop software. You can’t unread this information, and you will see software differently.
Dig in.