Layers of change: How buildings and software are alike | Hacker News Reader

Layers of change: How buildings and software are alike

medium.com

47 pointscolluder18 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.

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

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.

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.

I guess that's not what they wanted to hear. (honestly, it's a poor metaphor)

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.

It was just hunch that the article is about that book and after skimming the article seems like my hunch was right.

Good book, better (great) TV series https://youtu.be/maTkAcDbrEY

Off-topic, but the item ID of your comment is 33333333.

https://news.ycombinator.com/item?id=33333333

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's mainly to help software 'architects' sleep at night

I compare it to buildings a lot, especially when explaining things to non-technical stakeholders.

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.

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?

> 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"

Reply on news.ycombinator.com