Planning Your Program with the STAIR Process
You are learning a lot of new syntax and many new strategies for thinking about information and programming. However, all these skills and syntax details are not the most important part of the programming process. You can always look up syntax or find a new command on the online help. The most challenging part of the programming process is the creative aspect. You have to be able to visualize a problem and apply a solution to that problem. You also need a framework for your solution so that you don’t find yourself staring at a blank screen, wondering what to do next. The next section helps you create that framework.
You don’t have to take a class in software engineering or project management to take advantage of good planning strategy for writing your program. I was part of a group of computer scientists at Indiana University which devised a strategy named STAIR to simplify the project-planning process. This strategy helps you avoid the headaches of program planning. STAIR is an acronym for a general problem-solving technique, but that technique is especially well suited for programming problems. STAIR stands for State the problem, Tool identification, Algorithm, Implementation, Refinement. I will explain each of these steps now.
S: State the Problem
The first thing you must do is write down the problem in clear, concise English (or whatever your primary language is). This sounds like the easiest step, but it’s the most difficult. Your statement of the problem should plainly indicate what you want to accomplish–a sentence or paragraph that describes what the program should do. You should avoid the temptation to get technical here. The actual technologies, commands, and syntax are completely irrelevant at this stage. Your grandmother should be able to read and understand your statement of the problem. (Well, if your grandmother happens to be a hotshot programmer, get somebody else to look at your problem statement!) Later in the process, you will become confused, and it will be helpful to have a record somewhere of what you are trying to accomplish. In C#, I like to include my statement of the problem in the actual code as part of the summary.
T: Tool Identification
After you gain a solid understanding of the problem you want to solve, it’s smart to make a list of the tools you will use to solve that problem. Tools can be many things. They can be various commands or objects in the C# language, techniques (such as the random number algorithm I show you in Chapter 2), or structures (such as a while loop). As you gain programming experience, you will learn more tools, and you’ll have more practice applying various tools to programming situations. In this book, the program that begins and ends each chapter is devised to illustrate the tools introduced in the chapter. I usually write the names of variables I will need and any major control structures I will use. The exact order and details of how the tools will be used can wait. Often, I list tools that I don’t end up using. Golfers usually leave the clubhouse with many clubs in their bags. They can’t usually take every club they own, so they select a set of clubs that are likely to be useful for the course they are playing. Identifying tools is a lot like that.
A: Algorithm
After you identify the possible tools, think about your programming strategy. Programmers call a specific programming strategy an algorithm. (Nice sound to it. You have seen by now that programmers love complicated names for simple things.) Now it’s time to think about the order in which you will do things. Some programmers use flowcharts or state diagrams to illustrate how the code is supposed to act. For small programs like those in this book, I usually use a simple list of instructions on paper. By the time you get to the algorithm step, you are actually writing down a form of shorthand to record the kinds of steps you will be taking.
Let me emphasize again that the algorithm should be written down. If you work all this out on paper before you turn on the computer, your programming efforts will be much less painful than if you simply sit down and start banging away.
NOTE
IN THE REAL WORLD
As you begin to program, no doubt you will run into somebody who is an experienced programmer. Very often, that person will say something like “I never plan my algorithms.” Although many experienced programmers do not use written documentation for their simpler programs, ask them how long it took them to learn and how many mistakes they made when starting. At professional software development houses, programmers are often not allowed to start working on a program until the plan is developed. You don’t have to use STAIR, but if you do not use a scheme to plan your programs before you begin coding, you will run into big problems. If you don’t believe me, try writing programs without a plan and see what happens.
I: Implementation
You might be surprised that none of the first three steps require a computer. The best programming happens far from a computer. I wrote the core of one of my most useful programs on the back of an agenda at a very boring meeting. No computer was in sight, but all the real work could be done with paper and pencil. (Don’t tell my boss about this–he thought I was furiously taking notes about the meeting.)
The implementation stage begins when you turn on the computer and write code. When most people begin programming, they jump directly to this step. (Instead of the STAIR process, they must use the IR process.) If you can succeed by jumping right into the program without planning, that’s fine. Sooner or later, though, you’ll be totally clueless about how to proceed. That’s when you need to back up and think more carefully about the entire problem. Generally, the implementation phase is the easiest part of programming. If your algorithm is written correctly, translating it into working code is a simple matter. If I look at each line of an algorithm and can say, “I know how to do that,” the algorithm is ready for implementation.
Keep your STAIR documentation around. You never know when it will come in handy. I once wrote a program named ABNIAC that simulates a simple machine language computer. I got a chance to demonstrate the program on television, but I had written the program in Visual Basic, which works only on the Windows operating system. The television studio used a Macintosh, so my program would not run. Fortunately, I still had the algorithm on paper. Translating the program from one language to another turned out to be a simple task because the underlying algorithm hadn’t changed. (Java runs fine on Macs.) I had already done the hard work of creating an algorithm, so implementing that algorithm again in a new language was all that needed to be done.
R: Refinement
With all this planning, you might expect your program to run correctly the first time. It won’t. Even experienced professional programmers expect their programs to crash many times. A lot can go wrong. Keep a positive attitude or else you’ll get discouraged. When your program does not work, it usually gives you clues about what is wrong. Sometimes it crashes and gives you an error message. Although this seems bad, it’s a good thing because you get lots of information about what has gone wrong. The error messages in C# are reasonably clear, and the editor brings you back to the spot where the interpreter noticed the mistake. These tools can be very helpful in spotting your problems.
NOTE
IN THE REAL WORLD
The conception of the STAIR acronym is a good example of the problem-solving process. I was working with a team of computer science instructors who agreed that we did not have an effective way to teach problem-solving strategies to beginning programmers. We mulled over the principles for days. Although we all agreed on the basic framework, we couldn’t figure out how to make it easy to remember and use. The next week, I had a dream about climbing stairs while writing a program, and I suddenly woke up. My wife remembers that I sat up and said, “That’s it!!” Then I wrote the acronym STAIR on the paper I keep beside my bed. (This wasn’t the first time an idea had occurred to me in a dream.)
Although the principles are not at all new, the acronym for thinking about them was an innovation that is now used by many programmers. Perhaps the real lesson is that sometimes your best thinking happens when you aren’t trying. Take a break once in a while, and let your mind catch up. Maybe you, too, should keep a pad of paper by your bed.
As a general strategy for refining your program, look back at the STAIR steps again. Did you state the problem correctly? Did you miss a tool that might automatically solve your problem, or did you use a tool incorrectly? Did you define a solid algorithm that will help you solve the problem correctly? Did you implement correctly? Maybe you made a typing error or missed a quotation mark, something silly like that. (In fact, the problems that cause the greatest grief are usually silly, such as a period where a comma should go, misspelled variable names, and the like.)