Recently, a family friend gave my two children disc guns. The boys were thrilled; what could be possibly more fun than shooting your sibling? Our friend handed one gun to Blaine and one to Larrabee. Both found the on switch, pointed their guns at one another, and pulled their respective triggers. The guns made satisfying electronic beeping noises. The children felt the vibration of small electric motors. And, almost immediately, the guns sent foam discs flying at surprisingly high speed from their muzzles.
At least, that’s what Blaine’s gun did. Larrabee’s gun made the beeping noise. Larrabee could feel the motor whirring. But, to his great disappointment, no disc emerged from the gun. So, while Blaine could fire a steady stream of discs at his younger brother, Larrabee was completely unable to return fire. While I would have been unafraid to face a steady simultaneous barrage from both disc guns, I was now petrified; two brothers with only one disc gun between them seemed unlikely to lead to a happy, relaxing afternoon.
Fortunately, I am an engineer. True, as a computer scientist, I dealt mostly with abstractions (zeros, ones, algorithmic complexity, category theory, etc.), but as a software developer I dealt with slightly less abstract abstractions. After all, I have crafted real actual software used by real actual people. Software may be intangible, but, still, we call it software engineering, don’t we? The mere fact that the system in question was physical, rather than logical, did not dissuade me from debugging it.
By which, of course, I mean “taking it apart.”
In my defense, I started with a visual inspection. I looked into the mechanism and observed that pulling the trigger would release the bottommost disc in the magazine, but, beyond that, the system was a black box. Attempting to fire clearly released the disc, but instead of flying out the muzzle, it was sent sideways. Perhaps there was some sort of obstruction in the flight path? Nothing I could see, but it wasn’t easy to see very much. So, I demanded a screwdriver and set about the disassembly process.
My dissection revealed the workings of the weapon. There were two round objects bordering the path of the disc. The first was small and immovable; it was a guide intended to ensure that the disc went towards the muzzle. The second, larger object had ridges to grip the discs, and rotated when the trigger was pulled; it was the propulsive mechanism. And, quickly, the problem became clear: the motor was rotating the wrong way, effectively shooting the disc back into the gun. But, it was not obvious how to solve the problem. Perhaps there was a gear missing? Perhaps the motor was installed upside-down? Further disassembly looked challenging, and the risk of breaking something rather large.
Then, I had a sudden (and, sadly, rare) flash of inspiration: a DC motor will run in the wrong direction if the polarity of the power source is reversed! And, so, I opened the battery compartment, where, it transpired, my friend had installed the batteries the wrong way round. After reversing them, so that the positive and negative terminals matched the label in the compartment, and reassembling the system, much fun was had by all.
My first thought was that thinking like an engineer had saved the day. Rather than simply declaring the toy broken, I had investigated the problem, understood how the system worked, observed the failing component, analyzed the cause of failure, and, most importantly, corrected the problem. But, upon further reflection, I realized how being an engineer had worked against me. After all, human error by the consumer (my friend) was much more likely than mis-assembly by the factory. Someone less intent on finding a mechanical problem would likely have thought of the possibility of a human cause. For that matter, someone less comfortable taking things apart would have probably started with the one user-serviceable part: the batteries. So, sure, I can now explain the inner workings of a disc gun — but I could have solved the problem in 30 seconds instead of 30 minutes if I had come at it from a different angle.
I suspect I make analogous mental errors in lots of other situations. In 2015, I shall try to determine when not to think like an engineer. Perhaps I should start by making a requirements document and developing some acceptance criteria. Or is this a problem where thinking like an engineer is unhelpful?