A thought-provoking letter I received from David Flint of London begins:
I suspect that the greatest disability from which SP [structured programming] suffers is the title of Dijkstra's original letter. Ever since people have supposed that simply by avoiding GOTOs they are performing structured programming and that they have improved their code. I was very struck by this when attempting to explain the SP concepts to other programmers and analysts in the Post Office.
In my view the key to SP is not that programs should be structured. Every program has a structure, but SP says they should be well-structured. People resist this because it sounds subjective and because it is more difficult than simply banishing GOTOs. Programmers, at least in commercial shops, are too eager to code and too reluctant to think—perhaps you should write an article on why this is so and what might be done about it. (Actually the causes are fairly obvious I think.)
I was with David Flint all the way in this, up to the word obvious. I learned in the study of mathematics to beware of the words obvious or obviously. They are words designed to lull your thinking to sleep, which is just what we don't want to do. So here's a good rule for you—better perhaps than "eliminate all GOTOs":
Whenever you spot a "lullaby word," wake up!
Daniel Freedman and I have listed several pages of lullaby words in our Handbook of Walkthroughs, Inspections, and Technical Reviews. We use them as triggers when we're reading/reviewing specifications. They include such lovelies as: all, all the tune, every, may, only, same, should, too, will, certainly, therefore, clearly, obviously, or as any fool can plainly see. The existence of such lullaby words in our language suggests some of the reasons David might have been hinting at why people don't think:
1. Somebody doesn't want them to think and is writing or speaking in such a way as to discourage thinking.
2. Nobody cares whether they think or not, but our habits of speech easily discourage thinking by making us sound very sure of ourselves when we may not be.
Why would language discourage us from thinking? Well, most of the time (outside of programming, certainly) thinking gets you into a lot of trouble. In most work environments, you're risking your job if you think very much, because work has been routinized. Thinking is believed to be a privilege of management, like a rubber plant next to your credenza.
Even in your private life, thinking is expensive. If you had to think about each bite of food you ate, or each time you crossed the street, you'd have little time for anything else. So you routinize your life in order to avoid thinking and save your time for other things—possibly for thinking about things that require thinking.
The same applies to programming. If we do happen to find some simple rule that always works and avoids the necessity for thinking, then we should apply the rule. Save the thinking for where it's needed.
For example, PL/I and COBOL allow the use of abbreviations for certain keywords, but the abbreviations are optional. This means each time you code one of these words, you might have to think about whether to use the abbreviated or unabbreviated form. Although you can muster arguments on both sides, it really doesn't matter much as long as you do one thing or another consistently with a particular keyword. Therefore, I always eliminate unnecessary thinking by deciding once and for all whether to abbreviate a particular keyword. Consequently, I never spell out CORRESPONDING or ENVIRONMENT, and I always spell out CHARACTER and PICTURE. It's a stupid habit, but it serves a purpose.
Of course, if I were coding some material as part of a system with a different standard for those keywords, I'd willingly adjust my habits. But it would cost me some effort. Some of my thought would have to be diverted to remembering which system to follow. Naturally, I would appreciate having a system sparing me the choice, but I'm not going to waste any more valuable thought bemoaning its absence.
This brings up another reason why people don't like to think:
3. Thinking is tiring and may prevent other thinking.
When a programmer first starts to write structured programs, a lot of thought-saving habits have to go out the window. ("This is the way I write a loop," "This is the way I handle a three-way decision.") In the past these habits have been thought-saving, but now it will cost thought to replace them with other habits. During the transition, all we feel is the extra thought-cost and very little of the thought-saving.
But the "no GOTO'' rule is actually another thought-saving habit (for me at least). When I find myself starting to write a GOTO, I use it as a trigger word rather than a lullaby word. I say to myself: "Weinberg, you've gotten into a lot of extra thinking in the past when you unthinkingly wrote a GOTO in similar situations. So why not think a little now and perhaps save a lot of thinking later, when you'll need it."
All of the other rules of structured programming—or of any good programming style—are this type of trigger rule. They say: "When you recognize this situation, stop sleeping and start thinking."
You can't operate on full consciousness all the time, even when you're doing something as dangerous as driving a car. So you accumulate a set of triggers to wake you up when things are getting dangerous. When you are driving, the triggers are such things as red and yellow lights, sirens, balls rolling into the street, children playing, or drivers ahead weaving from side to side.
In programming, there are triggers in the code, such as GOTO statements, tangled IF-THEN-ELSE logic, homologous parts that don't fit, garbled interfaces, and any code requiring more comments than code.
In our workshops, we pass out "trigger buttons" to participants who need to learn to trigger on certain words they utter that get them into trouble—words they use to lull themselves or others to sleep. For instance, one of our favorite buttons is
THERE'S NO WAY.
Obviously (!), when you utter this sentence you're saying, in effect, "There's no sense thinking about that, since it's impossible." When we hear "There's no way," we immediately award a button the perpetrator has to wear until learning not to utter this lullaby phrase—or at least learning to catch the phrase as it emerges and use it as a thought trigger.
Another favorite lullaby phrase on our buttons is
WHAT CAN POSSIBLY GO WRONG?
This leads directly to the second part of David's letter:
For your religion may I suggest "Skeptical Design"? The key concept being that you should examine your assumptions and designs as you proceed. As your first sacred text I suggest Bertrand Russell's advice: "Whatever you believe; do not altogether believe it." Russell had rather larger questions in view, of course.
"Skeptical Design" is a super name for the new programming religion, though Russell would probably spin in his grave to hear his advice used as a sacred text. Next time you're particularly satisfied with the design you've just completed, don't ask yourself "What can possibly go wrong?" but instead ask "What can possibly go wrong?"
And, of course, this thought leads to perhaps the most important reason of all that people don't think:
4. If I think about it too much, I might discover something wrong with it, and then where will I be?
Once again, this isn't entirely a stupid idea. For dozens of years, in schools, we're taught"if the teacher doesn't catch it, it isn't wrong." So why make trouble for ourselves, when we know the teacher won't really have time to look at our work?
But computer programming bears very little resemblance to schoolwork. The "teacher"—the computer—looks at all of the work, and whatever is wrong is magnified hundreds or thousands of times. In school, it pays to bury your head in the sand—most of the time—so why should we expect people to behave otherwise when they're writing programs for computers?
In sum, I've come up with four "obvious" reasons why people don't think:
1. Somebody wants them not to think.
2. Nobody cares whether or not they think.
3. Thinking too much may destroy the brain for other purposes.
4. We never learned to think in school.
Obviously, there's no way this list can possibly be wrong or incomplete. Want to take up the challenge?
Here's a problem called the Island's Puzzle. It's been much discussed as a measure of different styles of thinking. It was originally published by Robert Karplus around 1970 and has been used in training teachers to recognize different problem-solving styles. For college students, it may be quite a challenge, but for professional programmers, it should be quite a snap. Or should it? Have a go at it, but be careful. Write down your answers and reasoning, then look at my notes and see how you react to them.
The puzzle is about islands A, B, C, and D in the ocean. People have been traveling among these islands by boat for many years, but recently an airline started in business. Carefully read the clues about possible plane trips. The trips may be direct or include stops and plane changes on an island. When a trip is possible, it can be made in either direction between the islands. You may make notes or marks on the map to help use the clues.
First Clue: People can go by plane between islands C and D.
Second Clue: People cannot go by plane between islands A and B, even indirectly.
Use these two clues to answer question 1. Do not read the next clue yet.
Question 1: Can people go by plane between islands B and D?
Yes or No or Can't tell from the two clues.
Please explain your answer.
Third Clue: (Do not change your answer to question 1 now.) People can go by plane between islands B and D.
Use all three clues to answer questions 2 and 3.
Question 2: Can people go by plane between islands B and C?
Yes or No or Can't tell from the three clues.
Please explain your answer.
Question 3: Can people go by plane between islands A and C?
Yes or No or Can't tell from the three clues.
Please explain your answer.