Software and Building Architecture Compared
Apr 14, 2012 14:05 · 608 words · 3 minutes read
People tend to only understand what they can see. For most people it is difficult to grasp more abstract matters without somehow visualizing them. Software is an example of such an abstract matter. Let us visit the process of developing software through a comparison with developing a building.
Everyone knows that in order to build something you will have to think about it first. Just putting some sticks together as you did when you were playing outside does not work very well for a skyscraper. For any construction you will need an architecture to design it first. After your architect has designed the project is has to go through some checks as to whether you will have enough sunlight in the house, enough ventilation and perhaps most importantly that the structure will not come down on itself! Ideally you only start building when both the architect, the contractor and yourself are satisfied that the building meets all requirements. Our knowledge on the construction of buildings has been growing since we first exited our caves and thus we generally can found our decisions during each step of the process on this knowledge.
Most people have not had the experience of just building some software that eventually crashes because they did not think it through, it is not something you do as a kid when playing outside. This makes things a bit more complicated to imagine, but the development of software is quite analogous to the development of some construction.
Coming up with a program is even more complicated than building a construction. It comes with all the issues mentioned above when creating a building. It first has to be designed, then it has to be passed along to someone leading the developers to check for practicality and ideally usability. After that it can be passed to the developers for the writing proper. The issue at hand being, however, is that in the world of software wishes from the client and the environment change continuously during the project. This causes an oscillation between the stages mentioned above creating long delays before the final product is finished. To make matters worse, the final product will not be the perfect fit to the requirements due to the delays.
Why does this happen, you wonder? There are several reasons. For starters the art of programming is still very young, learning from our mistakes. Even the Romans had some mishaps when building their famous aqueducts. This entails that we still lack the experience to found our design decisions on. Another reason is that demands and wishes change rapidly in our new hyper-dynamic society. When you set off on constructing a building you have a very good idea of why you want to do that, what it will take and what your usage of the building will be. Software projects are generally given less consideration.
A very contributing factor to the complexity of creating a software product is the fact that most cases the software has to integrate ‘perfectly’ in the physical process of the client, where most do not fully grasp their own process, and that it has to communicate with other software products. These other products might not be designed with the new scenario in mind and thus either need adjustment or another way around it has to be found.
So, this is why coming up with a software product is just as difficult as constructing a building, and is in most cases even harder. The next time someone asks why it takes so long to write (good) software you just ask how long it took to design his custom made house. :)