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.
There's an journalists' saying I've come across a few times: "Don't get it right, get it written." In a way, XP seems to be a paraphrase and extension of this sentiment: "Don't get it specified, get it working." Or something like that.
My approach is necessarily a weak implementation of the XP approach - programmin isn't what I do for a living, it's what I do when a colleague (or I for that matter) needs a tool, the IT department can't or won't help (both are equally common), or going external is too expensive. I don't have the luxury of a formal design cycle (I usually have at most a day or two to get something working that the 'client' can see and play with, and then they want to change things), I don't get to work continuously on the same project (so I have to understand today what I did last month), and once it works, it has to stay working. So why 'weak implementation'? Partly through lapses in discipline, but mainly because the overhead in pulling together a full set of automated test cases is usually greater than their marginal benefit. I generally content myself with a logfile routine that tells roughly where, when and how my code broke. But as I said, I don't program for a living.
Part of what I do do for a living, however, is build spreadsheets - and here comes a rant. The number of spreadsheet users who apply any kind of design methodology, however informal, can probably be counted on the fingers of one thumb. The modern spreadsheet is no longer a simple tabulating and adding machine - it'a a highly sophisticated construction kit for certain classes of corporate applications, and needs to be approached as such. Yet few indeed are the Excel references that will tell you as much (except the ones that are really aimed at VBA programmers). Hardcoded constants, obscure naming, spaghetti logic - it's all there.
The next moderately large spreadsheet you encounter, try evaluating it as an application - you might be in for a shock.
Interesting comment. XP isn't so much about "don't get it right, get it written", it's more about "now, get a little bit written right, worry about the rest later".
And baby steps isn't really an XP thing, "Divide and conquer", "a bird in the hand" etc. have been around for ages. It's just that Kent Beck happened to invent (or at least define) XP, and he's the best programmer at this I have ever seen.
I've followed up to some of the spreadsheet comments in my latest blog post.
Post a Comment