Where software and architecture are different
Here I collect weird and rough ideas about challenges I see about adopting Alexander’s theory from architecture to software.
Arranging atoms vs. arranging bits
Structure in software is different from structure in architecture.
In the physical space there are levels of scale and in the built environment especially there are relevant dimensions along those scales: from large objects like buildings to small objects to what we can still see with our eyes. Arranging matter on those scales takes more or less effort and material.
In software, these scales do not really exist, or are not as clearly visible, and do not have a similar relationship to resources.
Static buildings vs. dynamic software
The product of architecture is mostly static structure — a building, which at the time it has been built doesn’t change its structure much (it can, but only in limited ways).
The product of software is an application that responds differently to different inputs (although it also has a lot of static invariants).
The structure of software is easier to change afterwards than the structure of a building is.
These are not differences in kind, but of degree. And I propose that the difference in degree is important enough to be considered a difference between the fields.
Different weights of design and construction/manufacturing
Software engineering can be seen as more of a design task, as production of software can be reduced to the copying of bits, which doesn’t need as much thought and effort put into it than the construction of actual physical structures. Physical structures need to be designed and then constructed, and both of these task require considerable effort.
The environment changes
In architecture, the environment to built a house into changes very slowly.
In software, today your view out the window shows a beautiful sunset over your garden. Tomorrow, somebody built a garage there. The day after, there’s a skyscraper. The environment changes so quickly, and it even is reasonable to change your window every day.
Aging is different
When buildings age, their materials and structure change over time. These are caused by the environment, but impact the structure and material of the building itself, up to a point where the building needs to be repaired or is no longer functional.
When software ages, their material and structure does not change at all. It’s purely the changing environment that eventually renders the not-changing software unfit for further use.
Inspired by https://www.hillelwayne.com/post/crossover-project/are-we-really-engineers/
Tools and environment
In architecture you use tools to amplify your ability to modify materials.
In software in a way that applies too, but software tools often are also an environment we live in. For instance, a heavily customized text editor is as much a tools for effectively shaping text documents, as it is an environment you adapted to your personal needs and live in.
Communities in physical space vs. ideological space
Larger projects in architecture — developments — get their life from the unfolding process and from responding to events in time. This unfolding over time is rooted in the wishes and desires of the local community — people that live and work there, in the physical space of this community.
Software is not tied to a physical space and can be used anywhere. The people using software form a community too, but their community exists independent of any physical space (though it is still connected to time). They are purely bound by ideological space. What is the geometry of that conceptual terrain?