Amy Brown & Greg Wilson
Most software developers are ejected from academia into the jaws of the business of software with little preparation. Of course, they are equipped with good enough knowledge about some more or less relevant programming language, and maybe some algorithm, hopefully including the venerable linked list reversion, indispensable to pass the dreaded coding interview. But not much more.
Of course, the availability of free and open-source code, coupled with the rallying cry of Reddit users “read the source, Luke!” means that they should be able to pick up major ideas just by cloning the repository of their preferred software package, and peruse its source code while sipping their preferred caffeinated drink.
The reality, needless to say, is far more complicated. Source code merely does a good enough job at the transcription of algorithms (in the best cases), but it does a terrible one at conveying the nature of the high-level architecture that organizes and coordinates all of that code in memory once the application is running.
This proverbial lack of visibility of the “blueprint” of any software artifact is one of the reasons why “Software Architects” have such an important role in teams dealing with large source code bases, where “large” is defined in average as more than a hundred thousand lines of code (a threshold very easily accessible, I am afraid).
We need, then, some documentation about the architecture of the code. But, alas, documentation is not always available, not because Johnny cannot code, but because he does not want to document his work.
This is where the two tomes of “The Architecture of Open Source Applications” edited by Amy Brown and Greg Wilson shine. They provide a much-needed explanation of the structure and inner workings of major products available in the free and open-source software market, written by their authors or maintainers themselves. After all, who could better describe their architectures?
Put together, this work contains 49 chapters, each describing various kinds of applications: desktop utilities such as the Eclipse IDE or Audacity; source control systems like Git or Mercurial; server-side products like nginx, Moodle, or Riak; or developer tools like CMake, LLVM, or ZeroMQ. And much more.
Perhaps surprisingly, each chapter follows a different path; the architecture required to organize the code of each of these packages is, needless to say, wildly different from one another. Each one solves a particular problem, and the spirit behind the solution will vary accordingly.
Do not expect these chapters to be a “quick guide” to understand how to architect (is there such a verb?) your own project; these texts must be understood as individual use cases, each tackling a very defined set of issues, and each in their own way. You will have to come up with the architecture of your own projects, maybe starting with a wise decision and applying Conway’s Law before writing a single line of code.
And for that, these are truly inspiring chapters, including some background details about the size of the teams, the longevity of the codebase, and anecdotes about their evolution. The social context around the source code is pervasive, and it is an integral part of each project. One cannot separate the existence of a software project from the social structures underpinning its architecture. Both coexist and shape each other continuously.
That is, by far, the most important takeaway of these essays, and the most salient factor that readers should remark while reading these pages. Of course, the technical details are juicy; but they are not, despite the enthusiasm of each author and most readers, the most important part. The social networks built around free and open-source projects are a defining aspect; alas, they are another characteristic not reflected at all in whatever programming language chosen by the authors.
The two volumes of “The Architecture of Open Source Applications” are available for free online, under a Creative Commons Attribution 3.0 Unported license. But if you enjoy the content, you should also buy a paperback or digital copy, knowing that the editors are donating all royalties to Amnesty International. And to make the proposal even more enticing, the website includes the full text of two other gems: “500 Lines or Less” edited by Michael DiBernardo, and “The Performance of Open Source Applications” edited by Tavish Armstrong.
As stated on the website:
If you are a junior developer, and want to learn how your more experienced colleagues think, these books are the place to start. If you are an intermediate or senior developer, and want to see how your peers have solved hard design problems, these books can help you too.
Cover photo from the book website.