The recent collapse of the I-35W bridge in Minneapolis-- and the post-collapse analysis--is a reminder to us all that a large part of an engineer's job is figuring out what's wrong. Whether it's during the debug phase inherent in electronic project design (much less practical in civil engineering, of course), or post-project failure analysis, it requires skill, experience, intuition, coolness and the ability to resist snap judgments.

That's why I was somewhat annoyed to read some preliminary discussion that the collapse may have been due to a design flaw. It's much too early even to speculate, but irresponsible "experts" seeking some media attention, and a willing media, are already out there.

When debugging an electronic project, experienced engineers know that any initial perspective of what's wrong is often itself wrong, as well. Even the data indicating what's happening, or not happening, is often flawed.

You have to calmly examine the data and check its validity, as well as any underlying assumptions, and then formulate some possibilities, along with independent tests that would support or contradict those scenarios. You have to be sure you don't see just what you want to see, and that you don't miss what you weren't looking for. In the case of the bridge, there are many possible causes for its collapse--problems with design, materials, construction, maintenance or the condition of the substrate, among others.

But there's one other key fact usually ignored in most quick, preliminary, off-the-cuff punditry about possible causes. In many cases of dramatic failure, there's no single cause, but a succession of smaller problems and mistakes. Regarding the bridge's collapse, for example, the critical failure combination could be insufficient overdesign margin, combined with slightly substandard materials and otherwise-minor construction issues, all aggravated by improper maintenance.

Understanding such "perfect storms" takes serious and patient analysis. Many of these investigations take more than a year, for that reason. The public wants quick and simple answers, but the complex nature of modern technology doesn't allow for them, despite our advanced and sophisticated simulation, test, measurement and analysis tools.

But as electronics engineers, we should be grateful that we have some significant project-development advantages over civil engineers. We can test and debug prototypes on the bench, instead of after concrete has been poured; we can build multiple units to run parallel and varied tests; and it is far easier to perform stress and extreme performance tests on ICs and circuit boards than it is on bridges.

Even better, we can do all this in relative privacy, away from the public and comments from armchair pundits. So we have no excuses for not doing a thorough debug--except for that pressure from management, the market and the schedule.