Thumps and reboots
My dad, John Webster, got involved in electronics nearly 70 years ago. He enlisted in the Navy in 1941 and after surviving both Pearl Harbor and the Naval Battle of Guadalcanal, he was sent stateside, where he received initial training in radio communications. During his 29 years in the Navy, he worked largely in electronics, finishing up as chief electronics officer aboard the USS Providence (CLG-6) during its last tour in Vietnam, where it was flagship for the US Navy Seventh Fleet, and for a short time after it transferred back to San Diego (Dad retired in 1970).
Most of the electronics that Dad dealt with were old-school: vacuum tubes, custom circuit boards, large and discrete components, and so on. He said that whenever a piece of electronic equipment started acting up, his first course of action — if a quick inspection didn’t reveal a core problem — was to sharply hit the equipment on the top or side. As he explained it, heat and motion tended to loosen connections; a sharp rap would often re-seat those components.
I thought of that tonight when I got a text message from my wife that our dual-band 802.11n router suddenly stopped recognizing her laptop. When I called her, she said that one band wouldn’t accept the household password while the other band (on entering the password) would hang and eventually time out. After talking with her for a minute (we’re about 1,000 miles apart right now), I told her to go power down the router, wait about 30 seconds, power it back up, wait a minute, and then try again.
It worked.
I find it interesting that even as the physical hardware has become smaller, cheaper, more integrated and more reliable, it is our software — the virtual and digital connections — that tend to “come loose” over time. When a piece of digital equipment starts acting funny, how often is our first act — if a first inspection doesn’t reveal a core problem — simply to reboot or power-cycle the equipment? And how often does that, indeed, end up fixing the problem? And it’s not just with home equipment and home systems; I’ve seen the same approach applied to mis-functioning “high-availability” systems in large corporate environments.
This says something, I think, about the fundamental complexity (usually high) and quality (often lower than it should be) of the software, systems, and protocols on which we depend, both personally and professionally. We adapt as individuals and organizations to these systems, rather than having the systems adapt to us. And we all poke along together. ..bruce..
About the Author: bfwebster
Webster is Principal and Founder at at Bruce F. Webster & Associates, as well as an Adjunct Professor for the BYU Computer Science Department. He works with organizations to help them with troubled or failed information technology (IT) projects. He has also worked in several dozen legal cases as a consultant and as a testifying expert, both in the United States and Japan. He can be reached at 303.502.4141 or at bwebster@bfwa.com.