The software business and the commercial construction industry wouldn’t seem to have a lot in common. Just start with the workers: geeks in cubes versus people in hard hats and steel-toed boots. But going beyond the obvious differences, both industries operate with many of the same challenges and pressures. Let's start with the similarities and then look at how the building commissioning process may offer valuable lessons for the software industry.
Both industries work with very complex systems/projects (of physical hardware, coordinated work among many entities, and often an interface between physical systems and computer code). One of the common and powerful threads that shapes work outcomes shared by both of these industries is the time pressure to complete projects on-time often getting in the way of achieving quality targets and avoiding obvious, or subtle, difficult to detect, errors. In the software business programmers are under pressure to “ship” software as they call it, and in the construction industry it’s often the “get ‘er done!” mentality, but they are both the same and have very similar consequences.
If you haven’t lived in a cave for the past five years, you’re probably aware that the incidence of internet security exploits has exploded and many high profile data breaches have occurred with a variety of results. Banking information is stolen by banking Trojans or through undersecured databases, and personal computer contents are encrypted by viruses such as Cryptolocker which demand payment from victims to regain access to their data (Cryptolocker was recently shut down by the US Dept. of Justice). The examples are limitless and I won’t try to catalog them here.
Few of the problems with computer code are the result anyone’s deliberate maleficence (setting aside NSA meddling for the purposes of this blog post). They are simply errors of well-intentioned people who are in a hurry to get software completed, and maybe they missed a “;” at the end of a line of code, leaving some hole open that they thought they closed. The software business uses tools to try to identify holes and code is often peer reviewed, but the complexity (especially with layers upon layers of code “libraries” being used in one program which are not even written by the programmer) makes complete detection of every error nearly impossible. Black-Hat hackers can find these errors and exploit them for their own gain.
Turning back to the construction business, one of the reasons building commissioning exists is precisely to help identify “holes” in physical systems (and sometimes even literal holes!), but also in functional operation. Much of the process of functional performance testing is what they would call in the software industry “white hat” hacking: trying to find ways of “breaking things” and finding weaknesses, with the goal of improving them for the users, not exploiting them.
I am not certain that the software business has a comparably rigorous process like we employ during building commissioning—or if they do, whether they can deal with the massive levels of complexity in software systems. So what are the takeaways here? First, that with modern, complex buildings, one of the many benefits of selecting the building commissioning process for delivering quality projects is that in some ways you have a “hacker” working in your corner to try to identify problem areas and resolve them before they are ever a problem. Second, maybe the software business could learn something from the building commissioning process in the design of a more robust QA system.