Software systems have always felt more organic to me than any building. A building will go years without any major changes or renovations. Your average modern software application sees multiple changes per day. And the functionality of the software evolves quite iteratively and rapidly over time. It also has to respond to various environmental stresses.
The point of this essay is that buildings do change, but different parts change at different rates - and the same with software.
You don't change the language your application is written in every day, and likewise the structure of a building isn't changed every day. But the stuff inside a building does change frequently.
As someone working in a building that is 250 years old I can assire you that it too sees multiple changes a day. Minor changes sure. A wall being painted here, a cable being inserted there, a entrance being moved etc.
Sure walls being moved is a more rare occurance, but it too happened multiple times during the past years.
I think there are undeniable parallels between software and architecture. Architecture just operates on a longer time scale.
I think it's a stretch to try to analogize it to architecture. Your 250 year old building rarely grows. How often does it double in size? A code base can double multiple times in a year, particularly during a scaling up phase. How often does the entire structure of the building get replaced?
I think there’s a large disservice in comparing architecture and construction in the real world to software.
Software is more like keeping quicksand in your hands.
The construction of houses take mature engineering principles and calculations of a physical world to create buildings standing for centuries.
Most (not all) changes after construction is veneer - on the surface and replacing of bits 1:1.
Software on the other hand need constant attention and massive changes to the very foundation is not uncommon. It might go as deep as a change in hardware, say moving from one arch to another, or changing of the software architecture such as moving to a distributed, eventually consistent persistence layer or vice versa.
It’s not like concrete stops functioning if you don’t keep touching it either. Don’t get me started on build pipelines, testing, integrations etc etc
And next up: product!
Yesterday we thought it was a new empire state building buuuut it turned out we need to build a modern day coliseum.
Followed by “project management” - this may be the most obvious sign that we’re off in comparison. A building need project management! Software on the other hand is often ruined by it, as software is supposed to be malleable.
One is soft, the other is hard.
Trying to liken software production to building construction is something I’ve seen create various problems in this field of ours for a long time.
I think it's a reference to the book "How buildings learn". I haven't read the whole book but as far as I have read it goes like this:
people try to guess what the good building supposed to be and build it but later they have a change of heart or either some other people move to that building and have completely different outlooks of what their home should be like. Author argues there is levels to buildings and we should build bottom levels in a way that won't hinder later changes to upper layers because the bottom levels are unchangeable and you would be better off destroying and rebuilding it if you want to change those bottom layers.
Software seems to be related in a sense that the bottom layers of your app should be developed in a way that won't be in the way of developing new features because if that happens you would need to rewrite from ground up.
I've read Brand's book and your summary seems accurate. And isn't it sometimes said of still good looking old software: The extensions which have been added happen not to contend with the original core architecture.
I think it’s because this is an analogy that’s used explicitly and implicitly by non technical people. So I use the analogy in order to refute it.
What I say is, software is almost nothing like a building. Software doesn’t get built once; it grows over time. Even if you don’t change the functionality, external factors like security updates and changes in fashion force you to continually update it over time. A much better analogy, if you need one, is a garden or park.
I often ended up applying this simple principle to software, especially design systems, e.g. in atomic design where atom, molecules, organism, etc. Can be developed as layers with different pace of change and optimized around it.
I'm curious if anybody knows where the concept came from originally. Was there already something like that in Greek philosophy, or was introduced with the study of complex systems? Or maybe it was indeed from architecture?
Readit News
You don't change the language your application is written in every day, and likewise the structure of a building isn't changed every day. But the stuff inside a building does change frequently.
Sure walls being moved is a more rare occurance, but it too happened multiple times during the past years.
I think there are undeniable parallels between software and architecture. Architecture just operates on a longer time scale.
Software is more like keeping quicksand in your hands.
The construction of houses take mature engineering principles and calculations of a physical world to create buildings standing for centuries.
Most (not all) changes after construction is veneer - on the surface and replacing of bits 1:1.
Software on the other hand need constant attention and massive changes to the very foundation is not uncommon. It might go as deep as a change in hardware, say moving from one arch to another, or changing of the software architecture such as moving to a distributed, eventually consistent persistence layer or vice versa.
It’s not like concrete stops functioning if you don’t keep touching it either. Don’t get me started on build pipelines, testing, integrations etc etc
And next up: product! Yesterday we thought it was a new empire state building buuuut it turned out we need to build a modern day coliseum.
Followed by “project management” - this may be the most obvious sign that we’re off in comparison. A building need project management! Software on the other hand is often ruined by it, as software is supposed to be malleable.
One is soft, the other is hard.
Trying to liken software production to building construction is something I’ve seen create various problems in this field of ours for a long time.
https://news.ycombinator.com/item?id=33333333
What I say is, software is almost nothing like a building. Software doesn’t get built once; it grows over time. Even if you don’t change the functionality, external factors like security updates and changes in fashion force you to continually update it over time. A much better analogy, if you need one, is a garden or park.
I often ended up applying this simple principle to software, especially design systems, e.g. in atomic design where atom, molecules, organism, etc. Can be developed as layers with different pace of change and optimized around it.
I'm curious if anybody knows where the concept came from originally. Was there already something like that in Greek philosophy, or was introduced with the study of complex systems? Or maybe it was indeed from architecture?
"If Builders Built Buildings the Way Programmers Wrote Programs, Then the First Woodpecker That Came Along Would Destroy Civilization"
Dead Comment