The Timeless Way is Agile

I finally got around to finishing The Timeless Way of Building, by Christopher Alexander (most well known in software for being the source of the patterns movement).  The last part of the book is called "The Way" to build things.  His focus is physical architecture, but it is interesting how closely it resembles agile software development.

There are a few similarities that I see.  First, he advocates (or at least shows in his example) working directly with the folks who are going to be using the building(s) when designing it with the pattern language.  You design it together with them.  Similarly, agile seems to advocate the same process of working as closely as possible with those who will be using the system.¹

But Alexander goes on to say, using this real-world example of a health care complex he helped to build, that it almost failed (in terms of having the quality without a name) because even though it was initially designed using the pattern language, it was in the end passed off to builders who conformed the design to "drawings" (think UML) that ultimately caused it to lose a large amount of the quality. 

The point he goes on to make is that you can't just use the language up front and then go translate it into formal design techniques and end up with the quality.  Rather, you have to build using the language, and in particular, build each part of the structure piecemeal, to best fit its particular environment, forces, context, and needs.  This is the only way that you can get the quality.  Here I see another similarity with agile and its focus on iterations and regular feedback.  You build in pieces, adapting each piece to its whole as it is built and ensuring that it best fits the needs, context, forces,  and environment. 

He also says that invariably our initial ideas and designs for a solution don't exactly reflect the ways in which the solution will be used.  And this disparity between our design and reality gets worse as the solution grows in scope.  Again, this is true in software and why the regular feedback is important, but Alexander proposes repair as a creative process in which we better adapt the solution to its environment based on deepening understanding of needs or when the design just isn't working or breaks.  This is akin to what we call refactoring, and like we do in software, Alexander advocates a continual process of repair (refactoring).  And this process doesn't stop when the initial thing is built--we keep tweaking it ad infinitum.

This seems somewhat intuitive, yet in software we're always talking about legacy systems and many have and continue to suggest "rewrites" as the answer to software woes.  While I understand that this is one area where software differs from real-world building (in the relative ease that something can be redone), I do think that we software folks tend to err too much on the side of rewriting, thinking that if only we can start from scratch, our new system will be this glorious, shining zenith of elegance that will last forever. 

It is this thinking, too, that even causes many of these rewrites to fail because so much time is spent trying to design a system that will last forever that the system is never completed (or becomes so complex that no one can maintain it), providing the next impetus for another "rewrite of the legacy system."  On the contrary, some of the best software I've seen is that which has simply been continuously maintained and improved, piece by piece, rather than trying to design (or redesign) an entire system at once. 

What is interesting to me in all this is the similarities between the process of building physical structures and that of building software, the general applicability of Alexander's thought to the creation of software.  I continually see this in Alexander's writing.  In part, it is good to see a confirmation of what we've been realizing in the software industry--that waterfall just doesn't work, that pre-built, reusable modules don't really work well, that we need regular, repeated input from stakeholders and users, that we shouldn't try to design it all up front, that we shouldn't use formal notations and categories that create solutions that fit the notations and categories better than their contexts, environments, and needs, that we should create and use pattern languages that are intelligible by ordinary people, and more.

There is one last observation I'd make about The Timeless Way of Building, regarding the "kernel of the way."  Alexander says that when it comes down to it, the core (the kernel) of the timeless way of building is not in the pattern language itself (the language is there to facilitate learning the timeless way); he says the core is in building in a way that is "egoless." 

In some ways, I think the concern about ego is less pronounced in the software world--rarely is a piece of software admired as a piece of art--but at the same time, the underlying message is that you build something to fit just so--not imposing your own preconceptions on how the thing should be built.  For software developers, I think the challenge is more in learning to see the world for what it is, to really understand the problem domain, to look at it through the eyes of the users and design a solution to fit that rather than trying to foist the software worldview onto the users.  To put it another way, we need to build software from the outside in, not the inside out.  The timeless way is really about truly seeing and then building to fit what you see.

Notes
1. At this point, another interesting thought occurs to me about pattern languages; I see a relation to Eric Evan's "ubiquitous language" in that the language you use needs to be shared between the builders and those using the thing being built.  What stands out to me is the idea of building a pattern language that is intelligible enough by non-software experts to be incorporated into the ubiquitous language shared by both the domain experts and the software experts.  Software patterns vary on this point; some are intelligible and some are not so intelligible; we need to make them intelligible.