The Debug Analogy in AEC

Let's talk about software debugging in relation to what we do in architecture, engineering, and construction (AEC).

Many of us have done a bit of coding as part of our education. When I was at UC Berkeley, engineering students used MATLAB to learn the basics of software in a class that was widely recognized as one of the more difficult undergraduate prerequisites. One of the concepts we had to learn was how to effectively "debug" our work. Syntax errors were pretty simple to deal with because they were highlighted. We'd track variable values through code, write text file logs, and even write code for testing. In addition to actual debugging, we learned how to write functions, subroutines, and compartmentalize our code so the work was less likely to have errors. In one semester, we learned the basics, which merely hinted at the error corrections done by software engineers as they debug.

What does this have to do with AEC? Consider the following definition:

"Debugging is the process of finding and resolving… defects that prevent correct operation of computer software or a system. Debugging tends to be harder when various subsystems are tightly coupled, as changes in one may cause bugs to emerge in another."

Clash detection is actually debugging! In clash detection, two systems have been modeled in 3D at the same location, creating a logical conflict that has to be resolved. We use a dedicated software package, often Autodesk Navisworks, to find the clash. We hold coordination meetings to resolve the defects. And the hardest problems are those that involve multiple systems. Clash detection is perfectly described by the definition of debugging.

Different kind of bug altogether. (Source: A List Apart)

What can we learn from the direct analogy between debugging and clash detection? As an industry, we go to extreme lengths to improve the quality of our work to minimize the need to do clash detection. On very complicated projects, we co-locate our people to one place so we can increase communication. We have management methods for categorizing our clashes. And we leverage cloud computing so we can place all of our files in one place and combine them for analysis faster than previously possible. But are we doing enough?

At BuildingSP, we think clash detection is an outmoded way of working. We've developed tools that use clash avoidance to create clash-free mechanical, electrical, and plumbing (MEP) systems. We're working on automation to quickly increase the level of development so we see a more complete picture more quickly. This is the future of how we should work – faster, more strategically, and with fewer errors.

How can you help? If you model MEP systems, become a customer and give us feedback. If you work with someone who models MEP on your projects, refer them to us. And if you are a project owner, ask tough questions of your teams about the best processes for BIM.