I have huge respect for architects and civil engineers - and most other professions - and my comments are not meant to suggest that there’s nothing to learn from them. But software is not the same as buildings and we shouldn’t get too invested in the analogy.
Ultimately, most buildings get to a point where they are finished. Tenants move in and the building will stay structurally identical for At least the next 10 years. But a huge amount of software never gets to that point. There’s always a “next release”. Some releases change the structure of the software to fit in concepts that weren’t even considered when the original was built.
For some time now I’ve been using the phrase “software is more like a public garden than a building”. Gardens grow and evolve over time; gardens can quickly and easily be modified for different uses; there are complex dynamic interactions between the parts; users have broad latitude to do unexpected things with them; they even have bugs! (some of which occur long after it’s finished). To me, designing the first iteration of a software system is only one part of the problem. The real challenge is maintaining the “architecture” in the face of long term change. I’ve been wondering if software engineering is more like permaculture than architecture.
The problems in software come from the places where it’s different from anything else. So maybe I’m wrong to say that the building analogy is flawed. Perhaps it’s more accurate to say that it’s not a deep enough analogy to make a meaningful impact on software engineering.
Sorry, never saw your response. Agree, and often argue that architects should pay more attention to the fastpaced and generative lessons of software languages, processes and businesses. We should see architecture as less finished, because it rarely is. It always changes, it degrades, the business changes, the family changes, the city changes around it, it breaks it gets extended or fitout or rebuilt, and architects are only sometimes involved (rarely the same architects).
But just because architecture is slower (much slower), it doesn't mean it doesn't contain many of the same issues and challenges. But architecture as a process, the challenges of clients, user interface, communication in building or use, business interface, cost and time control, and not least the incremental effect of degradation and specialisation disintegrating the profession etc.. these have been well documented in our profession and are being experienced anew in software.
I love the garden analogy, architecture should also be more like gardens! We have this misunderstanding that architecture is permanent, but really it is just slow. Trees are nice, but we also need perennials and vegetables.. and mulch.
Ultimately, most buildings get to a point where they are finished. Tenants move in and the building will stay structurally identical for At least the next 10 years. But a huge amount of software never gets to that point. There’s always a “next release”. Some releases change the structure of the software to fit in concepts that weren’t even considered when the original was built.
For some time now I’ve been using the phrase “software is more like a public garden than a building”. Gardens grow and evolve over time; gardens can quickly and easily be modified for different uses; there are complex dynamic interactions between the parts; users have broad latitude to do unexpected things with them; they even have bugs! (some of which occur long after it’s finished). To me, designing the first iteration of a software system is only one part of the problem. The real challenge is maintaining the “architecture” in the face of long term change. I’ve been wondering if software engineering is more like permaculture than architecture.
The problems in software come from the places where it’s different from anything else. So maybe I’m wrong to say that the building analogy is flawed. Perhaps it’s more accurate to say that it’s not a deep enough analogy to make a meaningful impact on software engineering.