Software and Building Architecture Compared

People tend to only un­der­stand what they can see. For most people it is dif­fi­cult to grasp more ab­stract mat­ters without some­how visu­al­iz­ing them. Soft­ware is an ex­ample of such an ab­stract mat­ter. Let us visit the pro­cess of de­vel­op­ing soft­ware through a com­par­ison with de­vel­op­ing a build­ing.

Every­one knows that in or­der to build some­thing you will have to think about it first. Just put­ting some sticks to­gether as you did when you were play­ing out­side does not work very well for a sky­scraper. For any con­struc­tion you will need an ar­chi­tec­ture to design it first. After your ar­chi­tect has de­signed the pro­ject is has to go through some checks as to whether you will have enough sun­light in the house, enough vent­il­a­tion and per­haps most im­port­antly that the struc­ture will not come down on it­self! Ideally you only start build­ing when both the ar­chi­tect, the con­tractor and your­self are sat­is­fied that the build­ing meets all re­quire­ments. Our know­ledge on the con­struc­tion of build­ings has been grow­ing since we first ex­ited our caves and thus we gen­er­ally can found our de­cisions dur­ing each step of the pro­cess on this know­ledge.

Most people have not had the ex­per­i­ence of just build­ing some soft­ware that even­tu­ally crashes be­cause they did not think it through, it is not some­thing you do as a kid when play­ing out­side. This makes things a bit more com­plic­ated to ima­gine, but the de­vel­op­ment of soft­ware is quite ana­log­ous to the de­vel­op­ment of some con­struc­tion.

Com­ing up with a pro­gram is even more com­plic­ated than build­ing a con­struc­tion. It comes with all the is­sues men­tioned above when cre­at­ing a build­ing. It first has to be de­signed, then it has to be passed along to someone lead­ing the de­velopers to check for prac­tic­al­ity and ideally us­ab­il­ity. After that it can be passed to the de­velopers for the writ­ing proper. The is­sue at hand be­ing, how­ever, is that in the world of soft­ware wishes from the cli­ent and the en­vir­on­ment change con­tinu­ously dur­ing the pro­ject. This causes an os­cil­la­tion between the stages men­tioned above cre­at­ing long delays be­fore the fi­nal product is fin­ished. To make mat­ters worse, the fi­nal product will not be the per­fect fit to the re­quire­ments due to the delays.

Why does this hap­pen, you won­der? There are sev­eral reas­ons. For starters the art of pro­gram­ming is still very young, learn­ing from our mis­takes. Even the Ro­mans had some mis­haps when build­ing their fam­ous aque­ducts. This en­tails that we still lack the ex­per­i­ence to found our design de­cisions on. An­other reason is that de­mands and wishes change rap­idly in our new hyper-dynamic so­ci­ety. When you set off on con­struct­ing a build­ing you have a very good idea of why you want to do that, what it will take and what your us­age of the build­ing will be. Soft­ware pro­jects are gen­er­ally given less con­sid­er­a­tion.

A very con­trib­ut­ing factor to the com­plex­ity of cre­at­ing a soft­ware product is the fact that most cases the soft­ware has to in­teg­rate ‘perfectly’ in the phys­ical pro­cess of the cli­ent, where most do not fully grasp their own pro­cess, and that it has to com­mu­nic­ate with other soft­ware products. These other products might not be de­signed with the new scen­ario in mind and thus either need ad­just­ment or an­other way around it has to be found.

So, this is why com­ing up with a soft­ware product is just as dif­fi­cult as con­struct­ing a build­ing, and is in most cases even harder. The next time someone asks why it takes so long to write (good) soft­ware you just ask how long it took to design his cus­tom made house. :)