The Timeless Way of Programming
tomasp.net
tomasp.net
It's not architecture-envy, it's finding a parallel from a different discipline that applies to your own.
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.
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.
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.
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.
https://www.grammarphobia.com/blog/2013/07/architectural-cri...
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?
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.
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
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".
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.
#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.
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.
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.
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.
It's based on human character. Good people produce good code, or "timeless" code, bad people write "bad" code (means it's a tech debt).
That's some really reductive moralism that does not take into account any external factors on why the bad code was written.
Do you really think you're a good person because you're code is good?
That’s a bit of putting the cart before the horse… what if they think they’re a bad person because their code is bad?
Programming requires more conscious specificity than faith wants to indulge in, so we need more than it.