Route planning with Baby steps

I'm becoming more and more convinced that one of the most important skills for any programmer is route planning with baby steps, and I've never really seen anyone write about it.
I was first struck by this when seeing Kent Beck give an introduction to programming at XP2001, a conference about eXtreme Programming. He demonstrated writing some code to convert between an integer and the corresponding roman numerals using XP practices like writing test-first, pair programming, and constant refactoring. But the thing that impressed me most was the way the code seemed to emerge out of nothing, taking one small step at a time, with the code always working and always getting better.

Programming is very like walking. When you walk, to move forward you have to put yourself off balance, and run the risk of falling. But without that risk you will never get anywhere. In programming every time you change the code you break it. For example, in a standard editor, typing a single character means the code will no longer compile. This is like being off balance. When the code again compiles, runs and passes all the tests it is like being back on balance. A step forward is making a change that adds functionality or improves usability.

Any programmer can break the code. The most mediocre progammer if told what tiny step to take will usually be able to write code to take that step. Good programmers can envisage how to take big steps, writing a lot of code to solve a difficult problem. What was amazing about how Kent programmed was that he could see how to take a big step as a sequence of tiny steps, each of which left the code in perfect working order, with a tiny bit of added functionality.

Most programmers cannot do this, and it is a hard skill to learn. Good programmers often find it harder to learn, as when they take big steps they often get them right. The only way to get better at it is to force yourself to try it. When about to start making changes that will stop you checking in code for a week, see if you can make it a day. Or try and break a day's changes into an hour's changes.

I think, counterintuitively, that this leads to one of the biggest problems with XP. In XP, the customer has to present a sequence of small stories. The onus is put on them to break a product into baby step stories, and as I've said, this is not an easy skill to learn. The problem is not that the customer has a hard job, as XP acknowledges the customer is a key part of the team, and has a job as hard as the developers'. The problem is that this part of the customer's job is assumed to be easy.

By taking more baby steps, it is easier to deal with a changes in requirements, easier to test, easier to integrate with everyone else, and probably results in better, simpler code.