Programming Proverbs 2: Think first, Program later

This is the second of a serious of posts based on the book Programming Proverbs by Henry Ledgard. The index for the series is an earlier post and discussion of the list as a whole is taking place in the comments there. Comments on this "proverb" are of course very welcome here.

I used to talk to my students about the difference between "Ready, Aim, Fire" and "Ready, Fire, Aim" And for that matter "Fire, Aim Ready" Ready means "Define the problem completely" of course. One really has to know what the goal is. This involves a lot of thinking. So too does thinking about the actual code to be implemented.

There are a lot of questions to ask ones self about things as complex as algorithms and as simple as variable names and types. My own personal style is to think about the program I write for some length of time before I write the first line of code. Back in the card punch days (remember those? Probably not.) I used to write out a sort of outline on paper. I thought about the various pieces of the puzzle that make up a computer program and try to make sure I knew what I was doing.

These days with powerful IDEs I often create my outline in something that looks to the casual observer like code but really isn't. There may be function/method definitions but inside them is only comments. By the time I am thinking about the actual classes and their methods and data I often use the Class Designer in Visual Studio to block things out.  By specifying the methods and data for a class I can express in detail what the interfaces will be and use comments to explain what is going to happen inside them. Bit that is really still a form of thinking on paper not coding. Only later when I think I know what all the pieces are do I start real coding.

I think this proverb applies at least as much and probably more during the debugging phase. All too often I have seen students rush to through code into a now-working program in hopes that it will "fix something." A missing "End If?" Through an "End If" statement in some semi-random place in hopes of preventing the compile error but with no thought about possible logic errors. That sort of thing happens all the time. The worst thing about that sort of "problem solving" is that it introduces more frustration than solutions. The art of desk checking code and giving serious thought to what might be wrong seems to be all but dead.

During debugging a programmer really must sit and think. They must analysis their code, the error messages and what is supposed to be going on. Understanding and defining the problem must come before adding or changing code. Think first, Program later! 

Technorati tags: programming proverbs