The second most important part of writing any computer program or script is planning out your program’s “path”. You can do this in a number of ways; flowcharting is one common method. A program’s flow can also be referred to as its “logic”.
(Incidently, and completely unrelated to this post, the single most important part of writing any computer program is coming up with a good name before you start. My old pal Leperkhan taught me that, and it’s true. Come up with a good name for your program and a good program is sure to follow.)
Back in my middle school speech class, one of the speeches we had to write and present to our classmates was a demonstrative speech. The point of a demonstrative speech is to demonstrate a process to an audience. “How to make a peanut butter and jelly sandwich” was a popular topic that I remember at least three kids doing. Nothing more exciting than listening to several seventh graders in a row describe in great detail the steps involved in making a sandwich. What a waste; I always saw assignments like that one as an opportunity to torture my fellow classmates. It’s not every day that you are presented with complete freedom of choice over a topic and a forcibly captive audience. Of course, I come by this trait honestly; back when Dad was a kid he gave a speech in school on how to rob a bank that unfortunately matched the m/o of a string of bank robberies a little too closely. That one got him a few house of police interrogation. Fortunately my speeches never got me into any legal trouble, but I do remember hearing a few exasperated sighs during my thirty-minute classic speech, “How to get the most for your money at Taco Bell.”
At the heart of these speeches was the ability to take a process (making sandwiches or robbing a bank) and break it down into small, manageable steps. This is, essentially, what programming is. Sometimes, especially with scripts, programs are very simple. “I need a program that tells me how much free drive space is available on a remote machine.” For that you’re going to need a machine name, a drive, and a command that determines the free space. Obviously this is a extremely simple example, as this program only performs one function. When you start programming in things like Visual Basic (or any graphical type of programming language), you end up with a bunch of related functions that all do different things. Back in the days of BASIC or even most scripts, things tend to follow a logical path from beginning to end. Obviously the program’s path can be varied, perhaps due to input from a user or based off of a pre-determined result, but everything that a program does must happen in order. Things are slightly more complicated in a visual type of program, as users can perform a number of tasks in any order they choose.
It is this logic, the ability to plan out a program’s path, that determines how well a program works. For example, a couple of years ago I wrote a program that would report the amount of drive space available on several servers. The program ran once a day, every morning. If the amount of available drive space was greater than 10%, the program did nothing. If the amount of free drive space was between 0% and 10%, the program would e-mail me a warning. Although I thought it was a great idea, the program didn’t work right. I had several servers end up with 0 space free, and I never received a warning. Did you spot the logic problem? In each instance, the servers had more than 10% free the morning before when my program ran (so I received no warning), and then during the day a user copied so many files to the server that the drive completely filled up and there was 0 space free. Unfortunately I only wrote my program to warn me if the amount of free drive space was BETWEEN 0% and 10%, but I forgot to take into account the possibility that the result might actually BE 0%. The servers were going from more than 10% free one day to 0% free the next, and my script never caught it.
That’s the problem with programming and logic; you have to take every possible scenario into consideration. And when you’re programming something that accepts input from people, look out — you have to take EVERYTHING into consideration. One time, while beta testing a program at work, I was able to crash it at the login prompt. When the programmer asked me what I entered for my name I told him I had held down F1 for about five minutes and then hit enter. By the look of exasperation on his face I suspect he did not anticipate such genius. Never underestimate or overestimate the power of an end user.
If you can begin to think like a program, or at least think using program-like logic, you’ll find writing programs much simpler. The problem is, at least for me, it’s a hard skill to turn off at the end of the day. I’ll give you an example. Every day at work that I write scripts or work on a program, I find myself wondering about the logic programming that runs my building’s elevators.
My building has four floors (three stories and a basement) and three elevators. When idle, the elevators sit on the first, second and third floors. Like most elevators, over each pair of doors on every floor is an LED sign that shows the floor the elevator is on and, if in motion, the direction the elevator is travelling. I work in the basement but visit the third floor often, so I spend a lot of time waiting on elevators. I suspect, if one spent enough time watching the elevators, that a set of logic rules could be surmised through observation. While waiting for an elevator to arrive I often think about the code involved to run such a system. Right now, one of our elevators is out of order and the system is suffering. Obviously, the programmers did not take that possibility into consideration.
Susan says I should take the stairs more often.