There’s a certain class of programmer who seems to derive great pleasure in comparing programming to architecture. Maybe because architects are cool, or sound more grand than “programmer”. The author mentions Patterns of Software as profound, but in my experience it was mostly empty and contained only references to other work, without adding its own voice or perspective. At worst, it was pretentious and boring.
This is really misreading the whole concept of patterns in both architecture and software. The goal is not to somehow equate or even link the two disciplines. Instead it is to note that when you go about arranging stuff to do stuff (e.g materials to be buildings, or programming languages to be programs), it is likely that there will (over time) emerge ways of doing things (patterns) that you can (and likely should) use over and over again.
It's not architecture-envy, it's finding a parallel from a different discipline that applies to your own.
So I would rephrase the parent poster you replied to even though he replied himself.
There are many programmers that put cart before the horse - they think they should use those patterns even before they start to emerge in their systems and treat those patterns as some kind of a goal.
Whereas one should notice when pattern is applicable because it starts emerging as such - and GoF wrote down descriptions for people to realize what these are and have names to call it out.
Like if you would be tasked to build local "folks music" museum and you insist that it has to be built just like Guggenheim Museum because that is state of art of building museums.
So real architect should say "well for folks music museum - build a shed, put on some folksy clothing on mannequins, set mp3 player with folksy music, that is good enough ... what is your budget? ... well it will not be enough for top grade sound systems so maybe a smartphone instead of mp3 player with amplifier".
Most of people in software dev should stop pretending they are building next Guggenheim Museum and accept they are building shed from wooden planks.
> There are many programmers that put cart before the horse - they think they should use those patterns even before they start to emerge in their systems and treat those patterns as some kind of a goal.
Isn't that the whole purpose of design AND of patterns? You design your software first, and instead of reinventing solutions that already exist, you base them on patterns. It doesn't have to be a BUFD, but you should still map out your requirements before hand, and when thinking of your implementation, if it's a solved problem why not use the patterns that are accepted and available. That improves build-time and maintainability because you're using familiar patterns.
There's a time and a place for going full hacker and just start coding immediately and letting the pieces come together as they will, but lets not glorify it and certainly not call it the "right way" or imply that design before building is "putting the cart before the horse". Design should come before construction.
And you’ve misread the whole concept of my post. There’s nothing wrong with finding parallels with different disciplines. I don’t recall saying that at all. My gripe is that different discipline always seems to be architecture and the design patterns topic has been talked to death for over 50 years now.
Architecture as a default comparison makes sense on many levels. You don't make blueprints for pottery. The level of 'coincidental' design is much lower in architecture than it is in painting. There are much more specified 'primitives' that you can use in architecture that directly reflect the capabilities of the construction, etc.
And even before programming architecture was used metaphorically. 'Architecting a plan' and all that. It's not too difficult to understand how design in architecture differs from design in other areas, in a way that makes using it as a metaphor useful.
> And even before programming architecture was used metaphorically. 'Architecting a plan' and all that.
The verbing of "architect" is relatively recent, and certainly comes after programming. Historically, and outside the USA, one generally designs a plan, you do not architect it.
Architects design buildings, they do not architect them. Some kinds of software involve designing an architecture.
We should add that the use of “architect” as a verb isn’t a recent phenomenon. The Oxford English Dictionary has written examples going back to the early 1800s.
The earliest example in the OED is from a July 23, 1818, letter that the poet John Keats wrote to his brother Thomas after visiting Fingal’s Cave on the island of Staffa in the Inner Hebrides of Scotland.
Here’s how a poem in the letter describes the cave and its distinctive basalt columns: “This was architected thus / By the great Oceanus.”
Your view of language is incredibly prescriptive. If I want to, I can say architects architect buildings. There's nothing wrong with that. If there's a useful distinction between designing and architecting then there's 0 reason I shouldn't bring attention to it.
For example. If 'to architect' is synonymous with 'design', would you say someone architects a logo?
You are welcome to say whatever you like, with whatever words you like.
Yes, this may have been common practice in the early 1800s, and earlier. It ceased to be common practice in the Anglophone world for most of the 20th century, and only re-emerged in the software development community in the final decade of that century.
The fact that a particular language habit existed at some point in time is often worth making to people who don't realize that language changes and shifts. But if you're going to do that, I think it wise to also acknowledge that the changes and shifts also involve particular language habits falling out of general use.
At the end of the day language is a carrier for meaning, that's all it is. Its history doesn't matter unless it confers meaning in some way (which it often does).
In my opinion saying 'architecting' is meaningfully different from 'designing'. If people don't generally do that, then their loss is the shade of meaning that that difference implies
"A Pattern Language" was published in 1977. It has only been in existence for slightly less than 50 years. When it was published it was simultaneously a revolutionary and also completely niche book. It did not build on any kind of existing sub-discipline of architecture, and most architects ignored it entirely (an awful lot of them still do).
It took several decades for anyone to notice that there might perhaps be some interesting way to take what Alexander had done in the context of architecture and urban planning and apply it to software development. That did not happen "over 50 years" ago.
The reason why "the discipline always seems to be architecture" is because there are no other disciplines that are (a) synthetic (in the sense of being about creating something that did not exist before, rather than analytic) and (b) have an existing magnum opus that describes the patterns that humans have used for centuries to practice that discipline.
The sciences are not a useful parallel, precisely because they are analytical. Various artistic practices could be useful analogies because of their synthetic nature, but the practice of art is widely held to be a matter of personal self-expression, and hardly a place you'd go looking to find "best practices".
Thank you for correcting me. I was 10 to 20 years off. By all means, feel free to keep talking about design patterns for another 10 to 20 years then ;)
> I don’t recall saying that at all. My gripe is that different discipline always seems to be architecture and the design patterns topic has been talked to death for over 50 years now.
I concur with the spirit of this gripe. While architecture certainly might be ripe for fruitful parallels, I think it might be over-emphasized because most discourse is derivative regurgitation. Most people are not generating original insights from their own experiences, but regurgitating (at best mildly extending) Christopher Alexander (or other derived work). Christopher Alexander tied to mine architecture for systems metaphors (because that was his background), and a group of software folks back in the day tried to map that to software development -- in other words, a lot of it was purely incidental. And they were all barely scratching the surface; there are likely many other fields with many other interesting analogies. Fresh perspectives that try to mine new lessons (from different domains) would be really interesting.
I feel like people glamorize architecture in general. Sure the Empire State Building was probably fun to design, but 99.9% of architects are just designing bland office buildings or long hallways of apartment boxes. On average it's probably just as exciting as a software architect designing their 100th CRUD webapp.
A friend of a friend is an architect who designs McDonald's restaurants all over the Midwest. I'm not sure if that's how he envisioned his career, but it's steady work.
As a counterweight, the first few chapters of Patterns of Software (not the GoF book but Richard Gabriel's https://dreamsongs.com/Files/PatternsOfSoftware.pdf) constitute the #3 most profound piece of writing on software I've ever read.
I was going to post something similar. That book is phenomenal. It's also very frank about many matters. For example, despite Gabriel being a major Lisp proponent, he concedes that contrary to his expectations (and what PG suggests in http://www.paulgraham.com/avg.html) that Common Lisp with CLOS would provide a factor of 4 or 5 of productivity over C++, that in practice, for his team, it was only more like 30% (which meshes with with Fred Brooks' "No Silver Bullet" thesis).
#2: Christopher Alexander, "Notes on the Synthesis of Form" which is also mentioned in OP, and which I read based on the mentions in Patterns of Software. So that's another thing to thank #3 for.
> There’s a certain class of programmer who seems to derive great pleasure in comparing programming to architecture. Maybe because architects are cool, or sound more grand than “programmer”.
in my experience, when people say things like "Maybe because architects are cool, or sound more grand than “programmer”.", it's because not only do they not get the appeal of whatever it is, but they cannot even imagine anyone else doing it for any motive other than posturing.[1]
the true reason (at least from my perspective a someone who does enjoy the comparisons of programming to architecture) is that we already have a lot of intuition for architecture; there is something mentally satisfying about considering the way buildings are designed and constructed, and we have a more physical intuition for the forces and balance involved. software is a lot more abstract, so thinking of it in terms of physical architecture helps people gain some intuition for how all the parts fit together, or at the very least the illusion of intuition.
[1] an interesting analogy is gilbert and sullivan's "patience", where critics have pointed out that gilbert meant to write a parody of the aesthetic movement, but since he himself did not "get" the movement, all he could think of was that its members were conscious frauds, and therefore made that the thrust of the operetta.
At scale, architecture dominates materials. Meaning anyone can pretty much build a doghouse out of anything, but to build Notre Dame someone needed to have invented the arch, which can support a lot more weight than the sum of material used to construct it. The same applies to software. Kubernetes is more than the sum of it's parts.
No, GOF didn't introduce the "strategy" pattern. What they did was catalogue and describe the "patterns". Perhaps GOF invented the name "strategy", don't know about that.
While I'm sure they didn't invent it, there's a lot of power in naming something, and even more in making it well-known. And they certainly helped with those.
Good article! I love Christopher Alexander's work and I would never have found it, if it were not reposted over the years.
The key concept in The Timeless Way is the idea of a pattern language. This is a collection of patterns that is ordered and can be followed to produce a design with the quality without a name. Pattern languages are not static though.
It always strikes me as odd the author's perception of the Pattern Language as being changeable. The most intense benefit of the Pattern Language, and the title of the book, is that it's Timeless. It doesn't change.
Sure you can fill it with different variables, which is what the author means when he says it's not static. But it really is a static language-based attempt at capturing perfect form and life in buildings.
We'll always forget and re-discover what he wrote about, but chaining oneself to one particular structural language will calcify over time, unfortunately.
Why though actually can't we build the way our ancestors did? Is that knowledge all lost? The Palace of Westminster isn't a farmhouse but it seems like a pretty beautiful, functional, durable building.
We can, but we prefer to use way cheaper and faster methods because before the "ancestral" building is finished, with our modern methods, we have built, used, torn down and rebuilt several times.
The Palace of Westminster rebuild took 30 years, but that was a pretty exceptional case. Balmoral Castle took 3 years. I don't know how long more modest housing took on those days but I'm assuming in the realm of a year. Even a few years to build a larger building seems acceptable if you get something reusable for much longer, and more timeless. Anyway, I think it's interesting to compare.
You'd think we ought to at least be able to build some monumental architecture some of the time, even if cost is prohibitive for ordinary buildings as the argument goes. It's simply impossible to my mind that we command more energy than our ancestors could dream of and yet it's somehow "too expensive" to ever achieve the kind of works they did by hand. There are obviously factors at play which have nothing to do with cost.
Because we stopped making buildings to create shelter, or livable places. The process became industrialized, and serves the same goal as most processes in a capitalist society: to generate most profit at minimum cost.
Even though today we build things with minimum cost, there's still not enough housing for everyone. There's a housing crisis in every major North American city, caused in large part by lack of affordable homes (and no, not everyone can work remotely from Quaint Townville, Wherever -- in fact, most can't).
It does not cost a million dollars to build a single detached house. Closer to a quarter million for materials and labour, give or take the cost of land. Profit for the seller is what makes up bulk of the cost. Profit margin for the builder. Decades of steady profit for the bank that sells and services the loan. The purpose of housing has become to be an investment vehicle, not shelter.
We could easily afford to build and maintain enough housing for everyone. Create and sustain vibrant communities where people's basic need of shelter are met. But it's just not compatible with the capitalist mindset.
Meh. Such moral absolutism leaves no room for fate. I had a colleague once whose wife was dying of cancer and he understandably had severe trouble focusing on his work. That does not make him "bad people" even though his code wasn't perfect all of the time.
Good people do make good code, they aren't spared the struggle of life. His attempt at working would be seen as good. He didn't experience a moral failing, for failing to produce commercially viable code.
If I write some ugly code to get prod back online ASAP, did I immediately become a bad person? Or do I only become a bad person after some number of weeks passes and I haven't refactored it to clean it up yet?
