Software professionals learn a lot from technical presentations and articles. But sometimes a well-told story can illustrate technical concepts even better, in an entertaining and memorable way. This week, Lee Copeland tells why it's good to be a software bard, teaching your audiences hard concepts in a decidedly nontechnical way.
I am a storyteller.
If you've ever attended a class that I've taught or a presentation that I've made, you've probably heard some of my stories. Many of you know that I once hired an architect and together we designed a house. I was very anxious to dig a hole in the ground while my architect wisely sought to understand my family's needs and only then design a home for us. For years I've told clients to be patient-let's understand your needs first, then we can more effectively design a system to meet them. Don't be in such a hurry to begin writing code. But when I became the client, I fell into the trap that I had always warned others about.
Here's another one. A few weeks ago I was on a flight from Salt Lake City to Detroit. Something was broken in the cockpit, the glide-slope computer, whatever that is. It must be important because the pilots and mechanics seemed to be very intent on fixing it. After replacing the computer a couple of times it still didn't work. The pilot announced on the intercom that he was shutting down all the power in the plane and then turning it on again to see if that helped. And then he added, "It's like pressing Ctrl-Alt-Delete on your computer at home." Most passengers laughed. The software testers on board blanched with fear.
It's stories like this that I use in my presentations for two reasons. First, I believe that nontechnical stories can be used effectively to explain, illustrate, and even illuminate complex technical material. Second, I think sometimes our brains just need a respite from the onslaught of formal instruction.
Recently my wife returned from a conference of social workers. As usual, she brought home an armload of books which, as is her custom, she dropped on the floor in our bedroom near her comfy chair. One of the books was titled The Power of Personal Storytelling by Jack Maguire.
In it Maguire says, "The process of becoming a storyteller involves trying out a conscientious slowdown in our minds, traveling at our own leisurely pace, not only to get where we want to go, but also to make the getting there better." He's right-stories get us there better. Maguire gives us other reasons to be storytellers: Storytelling connects us more vitally with others, it develops our creativity, it strengthens our humor, it increases our courage and confidence, and ultimately it invests our lives with more meaning.
As software testers, we have a story to tell, a vital story-a story about risk, a story about quality, a story about improvement, a story about success. Too often we present our story in purely technical terms: defect density, defect removal rate, defect severity, defect age, expected loss, return on investment. Perhaps our story can be better told through other stories-stories that, while illustrating technical points, also trigger fresh ways of thinking, encourage and inspire creativity, offer innovative points of view, and perhaps just put people in a better frame of mind.
I hope you'll discover for yourself the power and joy of storytelling. What personal stories, like my house-building example, do you have to illustrate a technical point in a different way? Give it a try.
