What can we learn about our projects with a little data science and a lot of version control?
Locate the most dangerous code! Find where Conway’s Law is working against us! Know who to talk to about a change you want to make! See whether our architectural principles are crumbling!
Adam Tornhill’s book shows both how and why to answer each of these questions. The code archaeology possibilities are intriguing; he shows how to get raw numbers and how to turn them into interactive graphs with a few open-source scripts. He’s pragmatic about the numbers, reminding the reader what not to use them for. For instance: “the value of code coverage is in the implicit code review when you look at uncovered lines.” Trends are emphasized over making judgements about particular values.
Even better are Adam’s expansive insights into psychology, architecture, and the consequences of our decisions as software engineers. For instance: we know about the virtues of automated tests, but what about the costs? And, what is beauty in code? (answer: lack of surprise)
There’s plenty of great material in here, especially for a developer joining an existing team or open-source project, looking to get their mind around the important bits of the source quickly. I also recommend this book for junior- to mid-level developers who want to learn new insight into both their team’s code and coding in general. If you want to accelerate your team, to contribute in ways beyond your own share of the coding, then run Adam’s analyses against your codebase.
One word of caution: it gets repetitive in the intro and conclusion to the book as a whole and each section and each chapter. Whoever keeps repeating “Tell them what you’re going to tell them, tell them, tell them what you just told them,” can we please get past that now??
A few factoids I learned today from this book:
– Distributed teams have the most positive commit messages
– Brainstorming is more effective over chat than in an in-person meeting
and when it comes to the costs of coordination among too-large teams: “The only winning strategy is not to scale.” (hence, many -independent- teams)