When you use genetic algorithms, you don't 'plan' anything. You start with a large set of random code sequences, and test them to see which ones come closest to the answer you want. Then you throw away all but, say, the best 1% of the set, and build a new large set out of random permutations of those survivors. After a few hundred passes through the loop, you end up with code that performs the desired function--often surprisingly well--but whose workings are almost always incomprehensible to the human mind.

The best analogy I've seen for genetic algorithms is: "teaching monkeys to drive a bus by putting each one behind the wheel for five minutes, then breeding a new tribe from the two who make the bus move the farthest."

Genetic-style coders have practices like 'shotgun debugging': changing parts of the code more or less at random, then running the program again to see if the bug went away. It works.. sometimes.. unless it screws up the code so completely that you have to go back and rewrite everything from scratch. But in those cases where it does work, the resulting code usually ends up so badly organized that no one ever wants to touch it again.

Whenever you hear someone say, "yeah, that program sucks, but we don't dare change it," you're in the presence of code that's evolved randomly, rather than being planned.

Programmers, OTOH, start by doing a whole lot of bookkeeping to figure out exactly what is the program supposed to do.. and I don't mean just "crunch numbers." You have to have a good, solid answer for at least the following questions:

• What are the inputs and outputs?
• Where do the inputs come from?
• Where do the outputs go?
• What are the acceptable values for the inputs and outputs, and what values are forbidden?
• How do we guarantee that every input and output meets its validity constraints?
• What does the program do if it finds a forbidden value?
• What algorithm will we use to turn the inputs into outputs?
• How do we guarantee that the algorithm always generates correct values, and always terminates in a reasonable amount of time?

and for any real project, you'll find more.

If you really have everything squared away, you can write a mathematical proof that shows your program will always Do The Right Thing.

Professor Donald E. Knuth is one of the great-granddaddies of "knowing what you're doing"-style programming, and is credited with having sent someone a piece of code with a note saying, "Beware of bugs in the above code; I have only proved it correct, not tried it.'" Just for reference, Knuth is also the creator of TeX, a typesetting language that dominates much of the professional print industry. The version number of TeX increases by one digit of Pi every time someone finds, and Knuth fixes, a bug. The current version number of TeX is 3.14159, which ain't bad for a program that's been in professional use since the late 70s. As far as anyone knows, the last bug in TeX was found and removed on November 27, 1985.

That's programming. ;-)