modern architecture - when is less more?

November 15, 2019

When I first read Design Patterns in Software I was a bit surprised to see architect Christopher Alexander listed as one of the book’s key references. Known for advocating the use of standardized patterns to solve common problems in the design of the built environment, Alexander’s writings have been quite influential in the world of software.

As a technology leader trained as an architectural historian, the exchange of ideas between these two realms is especially significant to me. The use of patterns has long been a well-established approach to the production of software. However, there are other, more subtle relationships between modern architecture in the physical and software senses that I continue to consider.

Let’s take the issue of minimalism, for instance, as a way to pose the question: is less, as a certain well-known phrase would suggest, always more?

In the history of modern architecture, the answer can get pretty nuanced. Initially ascribed to Mies van der Rohe in 1947, the phrase “less is more” can easily be used to describe many stylistic aspects of some of his most famous works, like his Barcelona Pavilion (pictured here) or his Farnsworth House. But there is obviously more to Mies’s oeuvre than the formal language of those iconic works, some of which diverges sharply from what the phrase suggests. Modern architecture is also much more diverse than we might realize, so the iconic phrase could hardly encapsulate such a wide variety of approaches fully.

Software is no less complex, but the answer to the same question there seems more clear-cut, and it is a resounding “yes.” Put very simply, “less” of things we don’t generally want - complexity, ambiguity, dependencies - almost always leads to “more” in various kinds of desirable returns: deliverability, precision, productivity.

Yet as anyone who has shipped software before knows all too well, over the course of a project’s lifecycle our ability to remain aligned with a strict minimalist philosophy will almost inevitably be tested. At times, the answer to the original question may end up being a bit closer to “it depends” than we may like.

Even before we get to any of these junctures, though, it’s important to remember that so much of the environment that undergirds our work is defined by minimalism in a more direct but perhaps less visible sense: from the optimizations of our data storage solutions and operating systems to the user interfaces of the tools of our trade, minimalism essentially makes many aspects of creating software as we have come to know it possible today.

In a sense, software’s infrastructure has arguably undergone some of the most profound transformations vis-à-vis the question that I originally posed. As the concept of “infrastructure as code” has become increasingly mainstream, there is both an apparent abundance, even limitlessness, of actually scarce resources (like memory and computational capacity) as well as an ability to administer them with much more precision than before and, as such, the potential to be more of a minimalist in this one area than in the past.

For those of us involved with areas where size matters, like data engineering, aspiring to deliver more with less is likely to become increasingly important, especially in light of what this landscape obscures: that all of these resources are just as scarce as before, if not more so.

Needless to say, the nature of the problems we often face are not “minimal” either in terms of their ambitions or their actual practical scale. In this and other similarly mission-critical areas, our awareness of the broader environment within which we work is key. The desire to operate at an ever-larger scale of impact should not get in the way of remaining ever more aware of the ethical and environmental effects of solving our most immediate problems.