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 week's 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.
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