Troubleshooting Rule #3: Is it working as designed?

Sometimes you start by troubleshooting assuming something’s broken, when really it’s just not working the way you expected. Put another way, it’s “working as designed” - but you and the designer miscommunicated, or disagreed.

Some questions to ask:

• Electronics: Why did I expect to get that output? Does the physics really work that way? Is my expected value off by a factor of 10? Is the effect too small to notice? Did the configuration bits get set wrong? Is the watchdog timer dutifully resetting the chip because I told it to?

• Software: Is there simply no data in the file? Is there no error code because there was no error? Is the resource not found because it was removed on purpose? Is the software relying on some operating system service that’s now supposed to work differently than it used to? Did I override the behavior before, or set a new default? Are two modules expecting different things from one another? Is it “garbage in, garbage out” - did a date get mistyped, so I’m getting the right results for the wrong century, or am I asking for a different report than I thought?

• People: Why did I expect this approach would solve my problem? Is that person just doing the job he was told to do? Are we trying to solve the wrong problem? Is that person OK as they are? Is what they did actually acceptable, just not what I envisioned? Is the symptom itself illusory, wrongly reported, or just imagined, or not really harmful?

It’s a problem, but are you sure it’s broken?

Next rule: What’s changed since it worked?