But Does it Work?

When I was in the USAF, a long, long, time ago, there was a guy in my shop — Armand — who, no matter what we did around the shop, would ask, “but does it work?” For instance, when I was working on redoing the tool cabinet, with nice painted slots for each tool, he walked by — “Nice. But does it work?” I remember showing him where each tool fit, and how it would all be organized so we the pager went off at 2AM because the localizer was down (yet again), it would be easy to find that one tool you needed to fix the problem. He just shook his head and walked away. Again, later, I was working on the status board in the Group Readiness Center — the big white metal board that showed the current status of every piece of comm equipment on the Base — Armand walked by and said, “looks nice, but does it work?” Again, I showed him how the new arrangement was better than the old one. And again Armand just shook his head and walked away. It took me a long time to “get it” — to understand what he was talking about.

He wasn’t asking if the new tool board would fit all the tools we needed to do our jobs. He wasn’t asking if it would be easy to find the right tool quickly. He wasn’t asking if the new arrangement of the status board would make it easier to find any particular piece of equipment.

He was asking if anyone would really use it as intended.

Would the tools be put back on the neatly painted little spaces once they were used? If a tool broke, would we be able to find a replacement that would fit the neat little painting? Would people really update the state of every piece of comm equipment on the Base on the new board? Or would the new board being always partially updated, and sometimes more trouble than it was worth — just like the old one?

This points to two perennial questions we should always ask about technology — will people use it they way it’s supposed to be used, and will they use it at all?

I cannot count the number of times I’ve been talking to another engineer, pointing out some problem with a network, protocol, or bit of code, and they’ve said something like: “But that’s not the way it’s supposed to be used.” Let me tell you a secret: people don’t use things the way you think they should. They don’t even use things the way they’re designed to be used. People use things to solve the problem at hand. If that means turning the wrench around and using it as a hammer, or turning the hammer around and trying to use the claw as a screwdriver, or a screw puller. Sometimes it even works. Networking tools are no different than hammers and wrenches. The fact is that most protocols and features are more often misused than used in the real world. So if you’re designing something, either design so it can’t be used wrong (good luck with that), or try and really think about how it could be used, and figure in out of the box thinking.

Our second temptation as technology geeks is to start thinking, “this is so good that everyone should use it.” This is all fine when we stick to trying to convince people, but we cross a definite line when we start thinking we know better than someone else. If we’re forcing someone to take chemotherapy, no matter how good our intentions are, we’ve crossed a line we shouldn’t be crossing. Just because we think the technology is brilliant — even if we think it can save your life! — we need to be careful when we start to think we know what’s best for someone else. There’s this little word called freedom… We need to accept that sometimes people just don’t share our “great ideas,” and our really brilliant plan just doesn’t catch on. Learn to get over it.

So the next time you’re thinking about some great new thing you’ve designed, or building something really new and cool, ask yourself the question — “but will it work?” It might work technically, but what about when you throw human nature into the mix?

About that picture… One day I was driving across the flightline the day before a big air show — just piddling along making my way out to the shop, which was located just about the center of the three runways at the Base where I was stationed. As I drove out onto the ramp, there were the Thunderbirds all lined up, just having taxied in and set chocks. The SPs hadn’t arrived on scene yet, so there were no red lines up (and I had a red sticker on my Jeep anyway), so… I pulled up just a few feet from the wingtip and had a buddy take a picture. Just a few minutes later the red lines were set up, and the opportunity went away. You don’t want to cross those red lines — fastest way to eat concrete on the face of the Earth.


  1. mmkhan on 19 January 2015 at 12:14 pm

    always an pleasure to take time out of my TAC life and read your posts 🙂
    made complete sense, a few questions if I may,

    a. when you say out of the box thinking, what sort of approach do you start looking at a problem? in other words , what is out of the box thinking for yourself?
    b. not really a question, but the hyperlinks on this article, seem to be hidden in a way, i.e, they do not say they are hyperlinks until you point your pointer onto them, is that intended or would you like to change the color of text, whenever there is a hyperlink.


    • Russ on 11 February 2015 at 10:09 pm

      Out of the box thinking — for me, this is just trying to find another angle, or another model, that I can use to understand the problem and figure out a good solution. I always like to consider the “traditional” approach, and then I like to discard the “traditional” approach and see if I can find some way to understand the problem differently. For instance, I normally look at a problem in network design from a packet flow direction, rather than from the control plane, topology, etc. I find that not many people think about things in terms of packet flows, so it gives me a different perspective.

      Hyperlinks — I’ll see what I can do about those. I’d never really considered the color scheme, just used the format “out of the box.” Thanks for point it out.