As I read1 the works of Christopher Alexander, I grew increasingly concerned that the software industry may be missing the point of patterns. Well, maybe that's not the right way to put it. I think we may be missing the real value that patterns bring to the table.

For whatever reason, it seems we approach them (broadly speaking) almost as loose algorithms to be applied here and there as it seems fit. Or maybe we just see them as convenient ways to talk about things we already know, or maybe we even use them to learn particular solutions to particular problems. And then maybe we just use them because it is en vogue.

It seems to me that the real value to derive from patterns (as an idea, not necessarily as they are often proposed in the software world) is in learning to see and think about creating software in the best way. What Alexander proposes at the end of The Timeless Way is that it isn't using patterns or pattern languages, per se, that give our creations the quality without a name. No, he proposes that the value lies in helping us to recognize the quality and teaching us to build in the timeless way.

The timeless way is more than patterns. The thing is, patterns help us to get there. I think in some ways, we do get it. Those who are really into patterns do seem to recognize that patterns are not the solution to everything. The problem is, I think, in that we are not using patterns in the most profitable way.

I think part of the problem is in not using patterns as a language. We have numerous catalogues of patterns. To be sure, we do not lack for patterns, and sure, there is obviously value just in having these catalogues and in using the patterns here and there. But I think that as long as we see patterns as individual things in a pattern catalogue, we won't use them to their full effectiveness.

Perhaps what we need to do is to figure out how to use them as a language. Perhaps we need to weave them into our thoughts so that when we approach the problem of building software, patterns are there, guiding our thinking, helping us to best arrange a solution to fit the problem. When we use our natural language, it does the same thing. Our thoughts are constrained by our languages, but at the same time, our thoughts are guided by our languages. The ideas form in our heads and rapidly coalesce into some structure that is based upon our language, and the structure works because of the language--it tells us what works and what doesn't work to articulate our ideas.

I think that a pattern language would have the same power. If we get the patterns into our heads, then when we're faced with articulating a solution to a problem, we will think in terms of the patterns. The patterns will give form to our solution, and because they are patterns, the solution will work. The pattern language will both guide and shape our thinking towards things solutions that have the quality without a name.

But then, as Alexander says of "the kernel," once we master the language, we move beyond it, so to speak. The language is not an end in itself but a means to an end, a means to learn the timeless way. It shapes our thinking to the extent that we are able to perceive the way even without a pattern. And this is the superlative value in patterns that I think we're missing.

Patterns, in themselves, have value, but as many have noted, they can be abused and misapplied. The reason for this is not that a pattern (or patterns in general) are bad but that we're using them as an end in themselves. If we simply let patterns shape the way we think about designing software, if we let them become a language, then we will learn to use them in ways that make sense and ultimately go beyond them and build great software even where a pattern doesn't exist.

So how do we do this? Well, I think to some extent, we already do it. I think there are people who use the language, who know the way, without necessarily being conscious of it. And I think that there is a lot of great guidance out there that in a roundabout way does lead to building great software, even though it may not be conscious it is using patterns as a language. But I do tend to think that there is far more bad or failed software out there that has come about because the language is not known, it is not explicit.

I think that what we need to do is to continue identifying patterns as best we can, but we need to start thinking about how to more firmly incorporate them into how we create software. In fact, I think doing this, attempting to incorporate patterns more into development, will drive the further identification of patterns, to fill out patterns where we are lacking. I also think it will help us to realize how patterns relate to each other, which is a big part of using them as a language and not just a bunch of monads floating about in the ether. As we see them relating, see how they work together to form complete solutions, we'll better understand the language as well as the value of the language, and ultimately, we'll be able to impart that language to enable more of us to speak it.

This calls for those who build great software, who theoretically already know the way, to be introspective and retrospective. It's not just a matter of looking about in the software world for repeated, similar solutions. It's about identifying good solutions, solutions that bring software to life, not just addressing functional requirements, and forming from those solutions a language of patterns for building such software. What do you think?

Where the base language isn't expressive enough, you get a secondary pattern language accreting on top. Which doesn't mean the base language should necessarily subsume the pattern language - better that is just expressive enough to implement the pattern language conventiently as a library.

Taking off from what Greg is saying here: I used to love patterns, but I have come to realize (as others have done earlier) that a pattern is a result of a weakness in the underlying language.A pattern is a frustrated abstraction potential.There is a clear mismatch between the world of the physical as enjoyed by the architect and the world of informatics as enjoyed by the software architect. In the physical world, you see a pattern and repeat yourself everywhere the pattern is applicable. In the informational world, you do the same thing only if your language is too weak. If the language is good enough, you abstract away the repetition.