Layers of change: How buildings and software are alike(medium.com)
medium.com
Layers of change: How buildings and software are alike
https://medium.com/@glenn.sorrentino/layers-of-change-how-buildings-and-software-are-alike-faa8e644e9e8
19 comments
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.
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.
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?
Only if you don't consider the people inside the building or the more detailed furnishings like the type of toilet paper or soap in the bathrooms
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.
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.
The next one that tells me they are alike will get me to agree:
both software projects and building projects are:
- always late and
- always more expensive than planned.
Why even think about software as a building at all? Just think about it as software. I don't understand the urge to draw parallels to other fields.
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.
Off-topic, but the item ID of your comment is 33333333.
https://news.ycombinator.com/item?id=33333333
https://news.ycombinator.com/item?id=33333333
Good book, better (great) TV series https://youtu.be/maTkAcDbrEY
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.
It was just hunch that the article is about that book and after skimming the article seems like my hunch was right.
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.
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.
It's mainly to help software 'architects' sleep at night
I compare it to buildings a lot, especially when explaining things to non-technical stakeholders.
It seems another metaphor to describe "pace layering" in complex system.
Here's an article I always liked on the topic and inspired me years ago: https://jods.mitpress.mit.edu/pub/issue3-brand/release/2
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?
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?
> Layers of change: How buildings and software are alike
"If Builders Built Buildings the Way Programmers Wrote Programs, Then the First Woodpecker That Came Along Would Destroy Civilization"
"If Builders Built Buildings the Way Programmers Wrote Programs, Then the First Woodpecker That Came Along Would Destroy Civilization"