Chad Perrin: SOB

22 February 2009

Software design is not architecture.

Filed under: Geek — apotheon @ 03:21

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.

object oriented architecture

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.


  1. Your entire thesis is ignorant of what software architecture is. I’m not sure why you bothered to write about something you obviously you don’t understand yet. Read Mary Shaw’s book on Software Architecture and make this rant again the future when you’re a bit more informed.

    Comment by Read Mary Shaw — 22 February 2009 @ 08:23

  2. I’m always impressed when someone says “You don’t know anything! Here, read this book, because I don’t understand the principles well enough to actually paraphrase the relevant bits.”

    Oh, wait . . . no. I’m not impressed by that at all.

    Thank you for stooping to argumentum ad hominem, rather than trying something novel like “I disagree, and this is why.”

    Comment by apotheon — 22 February 2009 @ 08:41

  3. Having worked in construction (and having friends who still do), I believe your analogy of building the building and compiling software is inaccurate. I’m not sure many (or any) buildings exist where everything proceeded exactly according to plan from groundbreaking to ribbon cutting. It’s common for a pile of change requests to show up the same morning any new team (cement, framing, electrical, drywall, HVAC) does.

    Comment by chromatic — 23 February 2009 @ 01:15

  4. Welcome to SOB, chromatic.

    I’m not sure many (or any) buildings exist where everything proceeded exactly according to plan from groundbreaking to ribbon cutting.

    I’m confused. Where did you get the idea I said anything about everything going according to plan? I simplified a bit for the purpose of making a point, but I didn’t think I simplified that much.

    Comment by apotheon — 23 February 2009 @ 02:30

  5. If I understand your main point, I’d summarize it as “software architecture is like the architecture of physical structures only insomuch as it restricts itself to the safe, tried, and true.” Thus, the main business of software “architects” is to stifle innovation and insure conformity with established best practices. That resonates well with my impression of every self-styled “software architect” I’ve ever met.

    Comment by Sterling Camden — 23 February 2009 @ 11:44

  6. One really important difference between the two is that no viable software is ever really “done.” It’s always being improved and updated: this is why unit tests can be so useful, they are like permanent scaffolding that allows you to constantly change the structure and still have the building stay up. This constant change is probably the most important difference between software and architecture.

    Comment by Ajay — 30 July 2010 @ 08:37

RSS feed for comments on this post.

Sorry, the comment form is closed at this time.

All original content Copyright Chad Perrin: Distributed under the terms of the Open Works License