Relating Building and Software Architecture

Building Architecture

For whatever reason, I’ve never (yet) had much interest in the design of buildings. I have a respect for those who design them and all of the work that must go into them, but I have yet to be bitten by that particular bug.

So it always came as a bit of a surprise to me when so many design movements (modernism, post-modernism, gothic, brutalist, victorian) were about the architecture of buildings. The reason why suddenly dawned on me and seems rather obvious in retrospect.

It’s the same reason why people spend so much time and care about certain fields – specifically, the design of things that impact our everyday the most. Things like clothing and watches and phones and other things we carry on our bodies seemed obvious to me. After all, think of how distracting an itchy shirt or ill-fitting pants can be.

In a sense, buildings are a lot like clothing: we spend the majority of our day in them (well, most of us, anyway). It’s no wonder that a couple might pore over the floor plan of their soon-to-be house, a manager over the layout of their office, or even a child over the exact placement of their favorite toys. These seemingly small decisions are how we craft and sculpt our very environments. A lion may live in the jungle and a fish in the sea, but a human lives in a building.

While I might not have many opinions about how a wall is structured, the angle and materials of roofs, or the curvature of downspouts, these things all affect how I interact with the many buildings I’ve dwelled within. Many of these architectural decisions constrained what options I myself could even consider, determined long before I ever considered considering them. Thus the true importance of the somewhat-invisible art of architecture has begun to reveal itself to me.

Software Architecture

In this way, software architecture is similar. The architectural decisions made for your project constrain what you might be able to do within and the level of effort required to do so.

The parallels continue when considering the relationships between a construction worker and their building architect compared to a software developer and their architect. Often, the architect is frustrated that their vision and design is not coming to fruition. The implementers are frustrated that the design cannot work or could work better if made simpler. It requires good communication and leaving egos at the door in order to work together and iterate on improving the design.

This is not because the architect has failed as much as the architect cannot be finished. Good design is dynamic because good features are emergent. If software programs are tools, then it is the responsibility of the tool-maker to enable the user to determine some of their own needs. The tool-user decides whether their screwdriver is for inserting a screw, prying a stubborn enclosure, or creating an indentation.

Once the architect stops giving input or stops receiving it, they are relinquishing their role. If they are not addressing the needs of the end users or the needs of reality, the implementers have no choice but to take over in their stead. Keep in mind that the users might not be the intended set of people.