Why should I care?

I remember the first time I heard the term good program design; my first thought was, "Why should I care how well-designed my programs are? They run, don't they?"

Well, yeah, but so did the Titanic.

As a programmer, you're probably only thinking of programming from the perspective of "I write a program, I sell it or my boss accepts it, end of story." Unfortunately, that's not the end of the story for the program itself.

How many programs do you use every day that are still at version 1.0? Probably very few. That means that, after the program was written, somebody had to go back to the source code and modify the source code. That's where problems can come in.

Up to now, you probably started writing a program by writing one small part of it, then writing another part (and possibly changing the previous part), then adding another part, and so on. This is fine, except that if you start working on part "E" and it turns out that it's integrally reltaed to part "B", you have to either go back and rewrite B, or try to wedge your new code into the old code, just to make it work.

You can imagine the results.

There was a study done in the 70's that showed that programmers wrote, on average, ten new lines of code per day. Ten lines! Considering that non-trivial programs are thousands of lines long, you can see the problem.

One other major advantage to good program design is that the more time you spend designing your program, the more elegant solutions you can come up with. Efficient algorithms can run orders of magnitude faster than brute-force algorithms, as you can see in this comparison of algorithm speeds.

Pasta-laden programs, or, Spaghetti code

Often, in order to understand code that was written piecemeal, a programmer would print out the code, put a pen by the first line, and trace through the program, always keeping the pen on the paper and next to the current line in the program. When he was done, the results often looked like a plate of spaghetti, resulting in the moniker of spaghetti code for code that jumps around and is very difficult to read.

Remember, a lot of your code will be handed to someone else, either as part of your project or after you've moved on from a project. If your code is a mess (even if your program works fine), it will be much more time-consuming to modify the program. It will also be harder for you if you have to go back to the program later on.

Readability

The bottom line is that your programs need to be readable. That means that they must be structured, make a minimum use of obscure tricks, and be well-commented. Look at your programs as though you'd never seen them before in your life, and try to figure out how to make it easier for you to understand your code.

Testability

Once your program is more readable, it will be much easier to test and debug. Obviously, it's much easier to change code that's easy to read than code that's hard to read. And you'll be changing your code often.

Simple approaches

There are two ways of designing a program, top-down and bottom-up. Top-down is the most common, but bottom-up can come in handy every so often.

We'll ignore structured design methodologies (yes, they really are called that) for our purposes. Really, what we're learning are just informal ways of going through those formalized design methods.

Top-down design tells you to start with a very general description of your program, then to slowly get more specific. So first start with, say, only two or three sentences. Then write a full-paragraph description, then a one-page description, and so forth until you are so specific that you know exactly how to code everything you've described.

Bottom-up starts with specifics. You write down what you know you can program, then you piece those together into something more complex, and piece other items together with this to make something even more complex, and so on until you have a complete program.

FYI, you'll probably use top-down design 90% of the time. But, just frequently enough that you'll be glad you know it, you'll want to use bottom-up. It should be very obvious which one is more appropriate when you sit down and start to design.