Blueprints Are Not Architecture
As I wrote a couple of week ago, one of the reasons I started The Architecture of Open Source Applications project was to fill a gap I stumbled over while teaching at the University of Toronto. There are lots of books on software architecture (an Amazon.com search for that phrase produces over 600 hits), none of the ones I have looked at describe or analyze the architectures of a broad range of actual software systems in detail. Instead, they all spend their pages telling readers how important architecture is, and how to describe architectures using UML, Petri nets, and what-not. By analogy, it’s as if books on real (physical) architecture spent all their time talking about blueprints: how important it is to have them, different notations that can appear in them, tracking their changes over time, and on and on, without ever actually showing people the buildings those blueprints portray. I know this isn’t because the people who wrote those books weren’t familiar with real software systems—all I can think is that they believe people won’t be interested in the specific, only in the general.
Puzzling…
Why is it puzzling?
The best architects are not necessarily the ones who write books. Those who can’t, teach (with apologies to you, of course).
This might be a biting question, but to what extent do you find yourself wondering how to design a certain kind of application, and how do you go about researching how to build that kind of application? How well did your undergrad serve you in this regard, and what in particular did you learn there that students should still learn today?
I find most of my self-directed learning is aimed at figuring out how to build good abstractions for problem domains I am interested in. In turn, my knowledge of how different problem domain experts view the problem itself expands. For example, for text editing, Emacs, Vi, Smalltalk IDE and Visual Studio users all have different use cases and expectations on how to work with their text editors. Sampling all of these leads to a much stronger understanding of trade-offs in the problem domain of text editing. It also better educates architecture that could lead to innovation in text editing. Hope this example illustrates why I don’t find your comments “puzzling” at all.
It’s puzzling because great creators are also often great teachers and explainers in other domains: Feynman’s lectures on physics, for example, or any number of authors who have also written great literary criticism (Orwell being my favorite).