Iterate, Iterate, and Iterate again

I’ve been a big fan of iterating since before I knew I was doing it. When I first read The Pragmatic Programmer nearly ten years ago, I was delighted to read about the concept of Tracer Bullets applied to programming. The concept of tracer bullets (based on guns firing an occasional phosphorous round in order to aim in the dark) is to start with a skeleton implementation and slowly add functionality rather than try to deliver the whole ball of wax at once. The concepts rang true to me before I really understood what Agile and TDD were all about, and I was happy to see that people who knew what they were talking about confirm that my typical approach to software development had some merit. To this day, that’s generally the way I write code (shoot me – I don’t always use TDD for the crap utilities I write). When I write code, I start with barely more than an empty function, then I add, test, iterate and refactor until the code does what I wanted it to do. I’m not smart enough of a programmer to do it any other way, and I (usually) get the expected result in the end.

But I iterate everywhere. At work, I put together skeleton project plans. Then I slowly fix them and add deliverables and dates slowly until I have something that works. When I write music, I start with a basic structure – sometimes a melody, sometimes a rhythm, and sometimes a chord progression. I slowly plug stuff in, add and remove parts, and repeat until I have something I like.

I’ve found iteration most beneficial in writing. When I write seriously (as in hwtsam or my chapter in beautiful testing, or many of the articles I’ve written rather than this blog), I always iterate. I usually start by creating an outline, and making the outline headings the subheadings in the chapter. I don’t worry about coming up with clever names, I just make sure the order looks right. Then (either immediately, or in another “writing session”), I’ll start filling in some text below the subheadings. When I get blocked on one section, I stop and move on to the next section. Sometimes I only write something like “talk about cyz configuration testing here” – either because I don’t have the data I need yet, or more often, because I don’t feel like writing about xyz configuration testing yet. In a later session, I may make another pass, or I may focus on adding specifically to another section or two. I add sections and remove sections as needed. Eventually, I find (or at least try to find) themes I can link together. Finally, once I “think” it’s done, I close the file and come back to it in a day. Then I read it, ask myself “what the f…heck was I thinking”, and make edits and rewrites, save then close. Then I do it again. Then I do it at least one more time. Eventually, it “ships” and I’m done (but I seem to always find stuff I want to change).

I can’t imagine not iterating on any task with a semblance of complexity – but not everyone seems to be on board with my approach. I was talking with a colleague some time ago who was putting on a series of collaborative events at MS. I was eager to help, so I asked them for details – e.g. how long will it be, how will you break it down, what are the outputs and a few other similar questions. He answered, “the strategy doc is almost done, and when it is, we can start thinking about the execution”. Yuk – that just seems wrong to me. Perhaps I’m a cowboy, but this is another case where I’d rather settle on the basics, try it out, and adjust. Sure, you need a vision / strategy, but I don’t think you don’t need a 10 page doc written before you get some people in a room to work together.

Or perhaps I just need to plan more – or set up a pre-planning meeting to discuss the preliminary plan – but not likely.