Did It Ever Work?

I have not failed. I’ve just found 10,000 ways that won’t work.

Thomas A. Edison

As a troubleshooter, you have one big advantage over your fellow engineers and inventors: the things you are trying to repair worked at some point in the past. Inventors dream up new forms, which engineers take and adapt to a myriad of novel contexts. Manufacturers then replicate these models, putting them in the hands of the masses. After the many hurdles required to finally get a product on store shelves, the question of “Will it work?” has likely been answered in the affirmative.

Knowing that a machine once worked means repair can focus on restoring that ideal. Relying on these existing conceptual models, the prior efforts of inventors and engineers become assumptions that can pragmatically be taken for granted. Economics drives this expediency: it would be costly to revalidate the long chain of reasoning that led to a machine’s creation (scientific principles, marketplace conditions, design choices, testing, etc.) every time you wanted to make a repair. Put another way, it’s much easier to simply assume that you can fix it.

However, there’s a critical distinction between a machine operating as its designers intended and its ability to meet your needs. A laptop from 1986 may boot up just fine, but that’s little help if you want to run modern applications. A system’s operational status and its capacity to do useful work (from your perspective), are two equally important, but different dimensions.

Therefore, my personal troubleshooting script now includes challenging both of these notions, now and in the past. A malfunction is an invitation to reconsider the underlying need and the way it was being served by a particular system. Along these lines, one of my favorite ways to start an investigation is by inquiring “Did it ever work?”

I’m often surprised at the answers I get to this question.

Slipping Past The Guards

“My name is on the building.”

Henry Ford II

Let’s consider the vetting process that manufacturers use to ensure their wares will be suitable for a given purpose and accepted by their customers. For companies that design their own products, there’s usually a whole array of people, processes, and facilities to get all this right: prototyping, specification reviews, testing labs, quality assurance engineers, statistical sampling techniques, proving grounds, focus groups, etc. A company’s reputation and the profit motive drive their adoption: businessmen don’t want to damage their company’s image or the bottom line by releasing a shoddy product. Also, in an environment where information is free-flowing, things that work well tend to be rewarded with sales. People talk and word gets around, good or bad.

While the free market system creates incentives that reward good products and punish bad ones, the process is a feedback loop that takes time (and requires your participation!). If a bad product slips through the fine mesh of a company’s vetting process and then is pumped up by a well-tuned marketing machine, you may be the recipient of something that truly doesn’t work. I think the worst experiences I’ve had along these lines is when I was growing up. During Saturday-morning cartoons, the commercials for toys made them look so amazing! More than once I saved my money or cajoled my parents for some new toy, only to bring it home and have it break shortly thereafter. More often the disappointment was emotional: that thing I had coveted from afar failed to live up to the grandiose dreams fueled by those slick ads.

Great Expectations

It’s a subtle point, but expectations often color the response to “Did it ever work?” This is why I find it such an interesting question to ask while troubleshooting. In response, I will frequently hear complaints that indicate the original purpose for which a machine was acquired remains unfulfilled.

As CTO of Discovery Mining, I was the person responsible for outfitting a large portion of our business infrastructure. This was one of the most satisfying parts of my job: to identify a pressing need and then find the perfect thing to meet that need. To this end I bought desks, computers, fans, phones, printers, lightbulbs, toner, extension cords, surge protectors, routers, switches, cables, hard drives, tools, and lots of take-out food. I had a bizarre passion for product research, spending hours poring over spec sheets, diagrams, and feature lists to find exactly the right matériel to move our business forward.

However, as thorough and careful as I was, not everything I bought turned out to be effective. For example, early on when we still built all of our computers by hand, I outfitted our servers with removeable hard drive enclosures. The idea was to make replacing hard drives easier, avoiding the hassle of taking the server off the rack and opening the case. Well, that was the theory anyway. We eventually discovered that this particular brand of enclosure was unreliable and would cause disks to go offline. When managing storage in a RAID (Redundant Array of Independent Disks) configuration, having drives go AWOL was a big problem, as the rebuild times could last days and significantly slow a server down. More frightening was the risk of data loss: I had several white-knuckle moments when I wasn’t sure if an array was going to be recoverable. My expectations were that the enclosures would make swapping drives easier and be just as reliable as before. This turned out to be a wrong assumption. At the time, if you had asked me if they worked in the way that I envisioned, I would have said “Um…not really.”

Sometimes, I would buy something for our employees and follow up later, only to find that my purchase really hadn’t improved things. Often this was because there was a mismatch between what I heard and the actual needs of the person I was trying to help. Another variation on this theme was that a machine would have been sufficient for a given purpose, but our training program was inadequate, and so it wasn’t being used to its full potential. Lastly, I’ve seen mismatches between how a system is being utilized and its true capabilities: the perception may be that it “doesn’t really work,” but that’s only because the machine is being asked to do something it wasn’t designed to do.

It Worked A Long Time Ago In A Galaxy Far, Far Away…

“Past performance is not an indicator of future results.”

The Tiny Print From That Thing You Lost Money On

For those who employ machines to do their bidding, the passage of time results in an ever-shifting context that adds further complexity to the problem of recreating a stellar past performance. To illustrate, I like to think of a favorite pair of jeans that I once owned: this perfect specimen of denim had been patched and repaired so many times that I called them my Franken-jeans. The answer to the question “Did they ever work?” was “Yes!” However, that doesn’t mean these pants could be restored back to their original state—too many threads were missing.

The point is that even if a machine worked well in the past, that doesn’t mean you can (easily) return there. Classic car restorations are a great example of this dilemma: sure, that rusted ’57 Chevy may have worked in the past (specifically, in ’57). However, the ravages of time make the prior accomplishments of machines little more than historical footnotes.

Guard Your Time

Questioning if something ever worked is an important way to protect your most precious resource: time. At worst, fixing something that never really functioned can be a quixotic quest; at best, it’s not even repair, lying somewhere between engineering and invention. This line of inquiry can also reveal the unfulfilled purposes of the people you are trying to help, a problem that can be wholly independent of a machine’s functional status. As I’ve found time and again, assessing and then aligning yourself with that underlying need is the sure path to avoid wasting your effort.

References:

• Header image: Harris & Ewing, photographer. AVIATION, ARMY, COLLEGE PARK. TESTS OF CURTISS PLANE FOR ARMY. SINGLE CONTROL. United States, College Park, Maryland. 1912. [Photograph] Retrieved from the Library of Congress, https://www.loc.gov/item/2016863983/.