There has been a few good articles written about how we should or should not build software like we build houses. But for me, these articles were not really addressing the main point. Sure, I get that we build houses more like the typical Waterfall methodology in software, and that Waterfall has it’s haters (in my opinion for good reason). And I get that Agile is considered awesome way better amazing for building software (if a little super zealotry verging on religious). But if I knew nothing about building software or building houses, my money would be much safer and the outcome much more predictable if spent on building a house than software.

Lets look at the reasons:

  1. Architects. Sure, software has architects. I work with so many different variants of architect (Solution, Integration, Application, Network, Infrastructure etc etc) that it is sometimes hard not to laugh. But if I get a real architect…well, they actually have a piece of paper from both an educational institution and an industry body stating that they are actually trained as an architect. That doesn’t mean they are any good, but it at least means the title isn’t accidental and they may have some idea of what they are doing. Many of the architects I have met in corporate software are simply victims of the Peter Principle (no offence to the ones that aren’t…you know who you are!) :).

  2. Structural Engineers. I am not sure that development has a direct counterpart…perhaps it is the Dev Lead, perhaps the Application Architect. In building, these are the guys that take what an architect has designed, and make sure it works according to physical laws. Perhaps it is the lack of physical laws, but it still feels like software lacks this translation from pure architecture to belt and braces implementation specifics constrained to the real world.

  3. Developers vs Builders. I recently signed a contract to renovate a house. I was able to sight a licence to state that the builder had at least attained some level of proficiency as well as certification by the state. On the other hand, what do you ask for when you sign a contract with a developer? You really have nothing to go on other than prior work. And sure, you get bad builders (the bell curve is everywhere) but the variability is much greater in developers.

  4. Standards and Certifiers. I think this one is the real kicker. If I line up an Architect, a Structural Engineer and a Builder to build me a house, then each of them is beholden to build that house within the constraints of the defined building standards or line themselves up for significant penalties including the loss of their license. And I don’t have to guess whether they have met these standards, as at every stage their work is evaluated by a third party, a certifier. This is of course not foolproof. But compared to software? We don’t even have the concept. And you could argue that everyone needs a house and the safety of their house is important to their health, whilst this is not the case with software. However I think this is changing quite quickly as more people rely on software and more people are actively contracting the development of software.

Depending on what type of physical structure you are building depends on how many of the above roles you need to involve, but you can’t avoid building standards and the possibility of audit by certifiers. And in many cases, I think it should be the same for software. If you are building software just for yourself, or Open Source, maybe you are exempt. But if you are being engaged contractually by an individual or a small business for software development, then there absolutely should be some set of software standards and development certifiers to validate whether you have provided a saleable, worthy deliverable. And just maybe you should lose your “Software Developer” Licence if it isn’t.