Things you can’t learn in school: Troubleshooting

Andrea Marson wrote a great post discussing the art of troubleshooting within the context of engineering. This is a topic that has a great deal of personal meaning to me as well, as a forensic analyst investigating high-stakes and complex disputes involving real estate and construction.

Although Marson is an electronics and software professional, some engineering concepts are ubiquitous. Consider the following:

All Electronics and Software Engineers know that most of the time our job consists of debugging, instead of designing and implementing. To put it simply, debugging means to find out and to fix defects that prevent a system (it being either a piece of software or a hardware circuit) from working. Commonly, this process is known as troubleshooting. Young engineers learn pretty soon that it often turns out to be harder than designing and implementing.

Unfortunately, unlike in the tech world, most young engineers in the built environment aren’t typically spending their formative years debugging failed assemblies. In fact, it is usually the other way around — most engineers in the practice of forensics have decades of experience behind them.

Regardless, the concept of troubleshooting is essential to understanding the limitations of products, assemblies and systems. Yet neither the A/E/C industry nor the tech industry offer standardized academic courses on troubleshooting. As Marson states:

There isn’t—and there will never be—a troubleshooting manual. The problems are always different and, generally, they do not follow repetitive patterns. However, I think that some general principles should be taught anyway because they are helpful to define an approach that should be used as a guideline. For instance, almost 20 years’ experience tells me that separating complex systems into smaller subsystems in order to isolate the problem is usually a good idea. Many of the young interns that I supervise in my company do not follow this approach. When they deal with a relatively complex system that is not working, they just get stuck. But it would be almost impossible for anybody to find out where the problem is if the system is considered as a whole. So I suggest to them to break it into smaller pieces and to verify each one separately.

My nearly 20 years of experience in the field of forensics also shows that “separating complex systems into smaller subsystems in order to isolate the problem is usually a good idea.” However, sometimes taking a step back to look at an issue or collection of issues within the context of the whole can also be useful, in my humble opinion.

What’s the Point?

Perhaps the greatest difference between the tech industry and the built environment in terms of engineering is the feedback loops employed in both. A feedback loop is a system or component of a system that alerts one to the existence of problems inhibiting expected performance.

In hardware and software, the feedback is sometimes instantaneous, or nearly so. In the A/E/C industry, most people don’t learn of issues with their work product until months or years after the fact. And rarely if ever do the actual craftsmen involved in a failed assembly receive feedback about their flawed workmanship.

If more designers and craftsmen were also trained in the art of troubleshooting, they will better be able to anticipate potential failures. Flawed building components kill and injure a lot more people and cause a lot more damage than bad software or hardware typically do.

And that’s why I really like Marson’s suggestion that instead of evaluating future engineers based on academics alone, provide practical assessments that consist of trying to fix a broken system utilizing troubleshooting.


Image courtesy U.S. Marines