Have you ever felt like you were going in circles trying to explain programming to nontechnical people? Simply telling them what programmers do just isn't enough. In this column, Naomi Karten demystifies the programming world by showing nontechnical people how to think like programmers?on a basic level. This seemingly intricate journey starts with a few simple directions.
Do you have customers who don't understand the complexities of software development? OK, silly question. A better question might be: Is there anything that would help them quickly gain a smidgen of awareness of the complexities?
During my years in IT, I became used to customers who recoiled in shock at our estimates for tackling their requests. At the time, I had no idea how to help them appreciate the challenges of what they were asking of us. They certainly wouldn't have tolerated our lecturing them, and I knew we wouldn't get more than an hour of their time to explain our case.
In recent years, I've used experiential training in my seminars to help people "get" what explanations can't convey. Experiential activities such as simulations offer a way to help people learn from the inside out. In other words, they learn through experiences that enable them to extract important lessons on their own, rather than having these lessons foisted on them by others.
Directing Robots
Here's a simulation I have fun with that helps at least a few people get an inkling of the challenges of software development. This simulation came about when a group of nontechnical people in a company I was consulting asked me to help them understand what programming was all about.
I asked each person in the group to write out a set of instructions that a visiting robot could follow to reach their office from a major intersection a long half-block away. The office was on the fifth floor in an office park building that was set back from the street and had multiple entrances.
I explained that robots had no ability to think for themselves and would follow the instructions exactly as stated. The instructions must therefore be clear, precise, complete, and accurate.
As they got to work, their initial reaction of "Nothing to it" gradually changed to "Hmm," as they realized that this seemingly simple task required careful thinking and attention to detail. When they finished, I invited each of them to read out their instructions. As each one did, I asked the others to imagine themselves as the robot and to see if they reached the intended destination.
Take a Left Turn at the Sign
The instructions these fledgling "programmers" came up with reflected a serious effort—and delightfully off-base results. For example, one person's instructions had the robot successfully arrive at the building, where it came to a standstill by the elevator and proceeded to wait—forever. Another set of instructions directed the robot in one door and out another. It hasn't been seen since.
My favorite was the fellow whose instructions had the robot look for a street sign that was no longer there. I knew for a fact the sign wasn't there because this person had directed me to look for the sign while driving to his office, and I couldn't find it. Another person in the group explained that the sign had been blown down during a storm—four months earlier. The poor robot was left spinning in circles searching for the sign. (This robot, like certain people, doesn't know how to ask for directions!)
As they detected flaws in each other's instructions, the group began to appreciate that crafting accurate instructions is not as straightforward as they had initially imagined.
In devising the simulation, I'd originally considered having the robot start from the nearest highway exit. But this exit led to some circuitous turns that were hard enough to explain to living people, let alone navigationally-challenged robots. As is usually the case in carrying out simulations, people create their own complexities; even a simple activity provides many opportunities for learning.
One member of the group excelled at the activity. In addition to meticulously guiding the robotic visitor to the right building, the correct entrance, the appropriate elevator, and the fifth floor elevator button, her instructions said, "Turn right after getting off the elevator." Notice: after getting off the elevator—no smacking into the elevator wall for this robot.Traveling on New Roads
In debriefing the simulation, I explained that they'd just written their first program and helped each other debug the programs. I asked what they'd learned from the experience, and their comments included:
- There's more to this programming thing than I thought
- It sure does take a lot of instructions to solve a simple problem
- Sometimes, things that sound easy turn out to be a lot harder when you try it yourself
- It's easy to make a mistake and not even realize it
- I'm so used to driving the route that I never noticed the street sign was missing
- I suddenly realize how risky it is to give someone important instructions without having someone else check them first
- It's a good thing I never had to tell someone how to get here
Granted, these people barely scratched the surface of software development. But they got an inkling not only of the challenge of developing systems, but of developing systems that work correctly. They also gained some appreciation for their own responsibility as customers, particularly—as the fellow who had given me the misleading directions put it—when "our own information is wrong to begin with." Progress made!
I gave them each a miniature robot to keep as a reminder of what they'd learned.
Experiential training doesn't produce miracles, but it's a powerful technique that helps people gain insights they're likely to believe more fully, retain longer, and understand at a deeper level than when information is flung at them by others.
If you'd like to use this Visiting Robot exercise, go right ahead. I'd enjoy hearing how it turns out. Just remember to select a destination familiar to those who are trying it—and unfamiliar to the robots in your vicinity!
