My introduction to Timeless Way of Building

To bring my blog readers up to speed. I posted this status update earlier in the evening:

Random question: How have I made it this far and not read The Timeless Way of Building yet?

I got this response from Bill Karwin:

I just heard about Christopher Alexander within the last year too. Dunno why I had not heard about him previously, given how much he influenced the OO paradigm. How did you come across him, and what has resonated with you most?

I started to respond, but then Facebook cut me off. They seem to limit the length of comments (once again, for convenience we're giving up control... I seriously think 1,000 characters is barely enough to get started in), but since I control the spigot here and can be as long-winded as I like, I'll post my comment here. Without further adieu...

I've heard of him a lot because of his Pattern Language book, but I'd never heard of this one. Reading the Screw Interface Patterns article on slash7 today got me thinking about it again and I determined to check it out the next time I had a few free minutes.

After dinner tonight, I stopped by the bookstore to check out A Pattern Language. The introduction talks about the Timeless Way of Building as the metabook (my words) of Pattern Language and how they really aren't separable: one provides the context, the other provides the words. Timeless Way was on the shelf next to it, so I picked it up and read the introduction. I was mesmerized. People don't write that eloquently, myself not excluded, any longer.

There was a powerful quote in the first chapter, and one that I find ironic giving the state of design patterns and refactoring in programming.

But though this method [of defining architecture through patterns] is precise, it cannot be used mechanically. Page 12

I couldn't help but think of all of the tools that enable refactoring. How we've tried to reduce patterns into reproducible macros and missed the spirit. It's too bad, really. I think a proper understanding of design patterns, be they of the structure of the code or the interface to it, can lead to much better code.

I ordered a copy tonight (couldn't pass up the $25 savings by having Amazon ship it) and plan on devouring it. I'm sure there'll be plenty of notes on my Readernaut page as I work through it.