In 1999 my partners and I sold our 50-person Web consulting shop Adjacency to Sapient, a public IT consultancy. The next two years of my life were a complete blur of post-merger integration, recruiting and discipline development to flesh out Sapient’s nascent e-business consulting capability, plus an ongoing role selling and delivering client engagements to Fortune 500 companies (all this at the height of the first Web boom).
Frankly, I don’t remember all that much about that time, but a few seeds were planted during the period that have since grown into stout limbs that I find myself leaning on again and again. One of these sprang from a sidebar conversation I had with Shep Narkier during one of our many management offsites. At the time of our meeting, Shep was the global head of the Technology discipline (with Creative and Strategy, one of three disciplines that made up the company’s service offering at the time), and I was running the Strategy discipline. We were both logging heavy air miles in these roles, and so we took a minute to swap book recommendations to help make better use of our long seat-hours.
Shep gave me a list of his favorites, all but one of which I’ve forgotten. The one that stuck with me seemed like an odd one for a software engineer to recommend: it was a passionate architectural and urban design treatise from 1977 called A Pattern Language: Towns, Buildings, Construction, authored by a UC Berkeley architect named Christopher Alexander.
As Shep described it, Chris Alexander’s methodical parsing of architectural design principles into discrete units, and his systematic hierarchical nesting of patterns from the most general (e.g., “The Growth of Towns and Cities”) to the most specific (e.g., “Light on Two Sides of Every Room”) helped to lay the intellectual foundation for the modern discipline of pattern-based software engineering. I’m not a software engineer by any stretch of the imagination, but I’ve always had a passion for architecture and design, and I was eager to get my hands on a work that bridged this personal interest with my daily life as a technology professional.
As a work of literature or a practical manual of architecture and design, A Pattern Language has not aged particularly well. The more granular patterns stand up better (and have been richly exploited by Sarah Susanka in her wildly popular Not So Big House series), but the larger-scale urban design patterns read more like a utopian fantasy than anything resembling our modern reality of highly specialized service- and knowledge-work. But setting aside the specifics of the subject matter, the intellectual method on which the work is based is as fresh and relevant as any current work of strategic analysis. In effect, Chris Alexander reverse-engineered his discipline and exposed its inner workings as a kit of parts that anyone, architect-trained or not, could use to conceptualize a built environment, from its smallest detail to its most integrated workings. With Shep’s setup, it wasn’t hard for me to see this approach at work in everything from Linux to more recent rapid development frameworks like Ruby on Rails. I still can’t write a lick of code, but Chris Alexander helped me learn a habit of pattern-based thinking that has become second nature. I’m not sure I ever properly thanked Shep for this, so hopefully this post will find its way to him. Thanks, Shep, for the great recommendation.
Hello Chris
this is Sheppard, thanks for the reference
I have found the concept of using patterns more useful than ever, it’s descriptive power transcends applications, and helps place perspective on infrastructure as well.
Have been doing much with these ideas over the last 9 years