Mankind has been constructing buildings for over 5000 years. The Great Pyramid of Giza for example, undoubtedly a masterpiece of architecture and engineering, has been built around 2600 BC.
Constructing buildings has a few interesting basic conditions. First of all, there is – and always has been – a huge demand for buildings, driven by the rapidly growing world population. The requirements on a building are quite different depending on where it is located. In addition, environmental conditions are – or at least, can be – constantly changing over time. Still, the most important parameters like average family size and weather conditions tend to change rather slowly.
If you count in punch card-programmed looms, the concept of software is little more than 200 years old. Electronic digital computation is less than 100 years old. Thirty years ago, the available main memory size of a computer would just allow for creating software with a complexity that, compared to a building, would probably match a soggy cave, hopefully at least heated by a campfire.
Decades and Millenia
Despite the enormous growth of the Internet and the fact that computers today are ubiquitous and thus also account for a big demand for software, the lessons learned from a few decades of creating software certainly cannot match the lessons learned from a few millennia of planning and constructing buildings.
Not long ago, software was mostly stand-alone. Back then, data would mainly be keyed in, and reports printed out. Subsequently, data exchange between computer systems became more and more important. Today, the focus is not only on exchanging data, but on keeping data synchronized between different systems.
Today, there are virtually no stand-alone systems anymore. Software interconnects to and interacts with other computers. Buildings are no different. An architect needs to think about the environmental conditions, for instance. Are we building on sand? If you have read the Bible, you know how this will end. If you did not, take a look at the Leaning Tower of Pisa.
If we are sure that we have chosen the right place to construct our building, further questions arise. Where do energy and water supplies come from? Are we planning to heat the house with oil or gas? We probably will not enjoy ourselves a lot in winter if we plan for gas heating, but there is no gas pipeline into our house. In warmer countries, central heating may not be an issue at all, at least, as long as the climate does not change significantly.
Supply is not the only thing that matters, by the way: where does used water go, for example? Creating our own soakway might be a good idea at first glance, but has a limited capacity. Or we might pollute the drinking water in our own well. We thus realize that we just cannot just build a house in some remote location, unless we are willing to generate our own energy, dig our own well, and hope that some means of mobile Internet access is available.
Software is less tangible
While a self-supporting building might be quite appealing, as soon as technical problems occur, or we are short of wind, sun, or whatever we create energy from, a large central energy supply and redundant distribution network suddenly comes in very handy.
Software is far less tangible than buildings. Nobody will sue you for trying to create a bloated, oversized, or completely inappropriate architecture, even if that could really help in some cases. If you submit blueprints to your local building authority, they will be put on public display for feedback. Even if all of this seems like a big hassle, it is, in fact, a rather efficient sanity check of a concept.
Beyond all those technical issues there is another thing to keep in mind: a building should fit nicely into its environment. You just cannot put a post-modern skyscraper into a traditional Bavarian village. Well, in all honesty, you could, but you would certainly have to expect a lot of trouble.
Software architects must be able to see the big picture. This includes being aware of neighbours, suppliers, outlets, and, most importantly, taking important non-functional requirements into account.