It seems that, when one discusses software architecture at all, someone inevitably brings up building architecture. The two are compared, and conclusions about software architecture and design are drawn from physical building architecture and design. While the relationship between software architecture and physical architecture is closer and more equivalent in concept than some might think, that closeness can be misleading, and lead people to inaccurate conclusions about software development.
In many cases, putting together a new building consists of little more by way of analogy than burning a copy of a program onto a new CD — though of course, in reality, there’s a lot more to it. The actual analogous activity to writing up the blueprint of a new building design is writing the source code for a truly new program design, because what the builders at the site are doing is analogous to what your compiler does and not what the programmer does. The way many software dev shops divide up the job of software development into programmers on one hand and “architects” on the other is akin to breaking up the job of a physical architect into “idea guy” and “pencil guy”. Of course, the skills involved in software development are different enough from those in actual physical architecture that I’m not sure that’s really a valid comparison for coming to any conclusions about this software development practice.
On the other hand, most buildings are primarily duplicates of previous buildings, and there’s some similarity with software in that there are scads of CRUD applications created every year that do roughly the same thing, but at the same time there are more essentially new software designs every year than new building designs.
I think that builders are unavoidably more risk-averse than software vendors in large part because of the greatly increased cost of copying where buildings are concerned. If you think software development has gotten into a rut, with new programs being to a fair degree just rip-offs of old programs, you should try getting a degree in architecture and finding a job where you’re allowed to do “interesting” and “new” work with physical structure design, where something new and untested that causes the structure to collapse will cost tens of thousands of dollars at minimum, and that’s just during the “beta test” stage — let alone in production, where people will likely be inside it and get killed by the collapse.
Beyond that, there’s also the simple fact that there is not the same need for innovative architectural techniques when constructing buildings as there is in the software industry. The very ease with which completed software is duplicated and distributed completely changes that dynamic, as does the way the software industry operates (influenced by corporate culture, the environment engendered by strong copyright law, and other social and economic environmental factors). Perhaps more importantly for explaining the differences between how the field of architecture progresses and how the field of software design does so, however, is the cost that is passed on to the end consumer.
Software’s marginal cost is near zero — because once it’s “done”, it’s nearly free to duplicate it. Distribution can cost a lot of money, but it certainly doesn’t have to, and it is (perversely enough) largely the fault of traditional software business models that attempt to duplicate the form of business models that revolve around physical product that imposes any nontrivial distribution costs at all. Keeping all that in mind, the major production cost center is also quite reasonably the major target for investment in innovation. With actual physical construction, however, the major cost is in duplication because the marginal cost is so high. As such, it makes sense to devote far greater resources to innovation in the building process, rather than focusing on the designing process.
For this reason among others, it is only in very limited, incremental changes that any “advances” are made in the techniques used to develop new buildings. For the most part, one might expect that nobody really spends any appreciable money on improving the design process itself, because all the money is going toward improving building materials and similar actual construction costs — except in cases of specific needs, such as improved earthquake tolerance. There’s no object oriented design in the field of architecture, as far as I’m aware, and that’s because architecture just hasn’t gotten that far. Give it another thousand years, though, and building architecture may have caught up with today’s software architecture in terms of the growing complexity of structures.
In truth, software design bears a lot in common with architecture. They are similar enough that, in theoretical terms, the word “architecture” really fits software design quite well. In the real world, however, it leads people to make comparisons that don’t really work — and the similarity of practices convinces people to overlook the obvious problems entirely too often.
Put another way, software design is architecture, of a sort — but the field of software design today is quite different from that of architecture. Give it a century or two for the field of architecture to provide better insights into the field of software design as it exists today. Given another five years of software design innovation, however, and we might have to wait another couple hundred years for building architecture to catch up.
Of course, that doesn’t guarantee that all this “innovation” is going to be good in the long run.