5:04 am, I’m scurrying around my desk like a mouse (rather, like a semi-bearded rat), anxious to check my task-list and count bugs.

I remember the day a manager at work suggested we might adopt a ‘rolling kanban’. No end to the task-list. Never. It sounded terrifying.

Well – I guess everybody’s different – I like the 2 week sprint. Crisp, short, but not too short. Long enough to waste half a day not really working. Not working at work is good, it makes the office a friendly place. Short enough that we need to rush a little to get done done towards the end. Neat. You got me, I like working off a small batch, enjoying a white mocha and breaking a brown sweat. I also like ticking boxes off a list, throwing lists away and making new lists.

So why aren’t we done done already?

Done done says it all. It sits high on my Agile Friends List when I’m in the office. I do like ticking’em boxes and turning a page.

On the other hand, when I’m working on my own stuff… well… The psychological cogs are somewhat different, and I even find positive aspects to leaving things just done. (half-done, you see).

1. The illusion of speed. Aye. Codeworks is snailworks. Painfully slow. I like to half-bake something, pretend that I’m moving swiftly to the next task, then go back again. If you’re walking from Paris to Rome, you might as well dance along the way, 3 steps forward and 1 step back. You won’t arrive earlier but you might actually enjoy the trip.
2. I won’t ship it if I don’t have it. There has to be a day when I look at my stuff and I think this is it, we have a game. And the sooner this day comes the better, because the enthusiasm of the first few days wears off all soon enough, and velocity will drop and drop and drop as deadlines swoosh by, weeks pile up and your family and friends start looking at you with generous commiseration.
   But when this day comes, I grow wings, and it really doesn’t matter that there’s another 3 to 12 weeks to go. What matters is, I’d rather it be 3 to 12 than 6 to 24 just because I’m not feeling the wind in my ears.
3. There is a good time to read code. Working monolithically, getting features done done one by one, could mean we’re coding forward and never looking back (pending refactoring). Granted one should beat the iron while it’s hot (easier and faster), I often find it redemptory to look back at my code 2 to 6 weeks after I wrote it. At this point I can look at it more objectively, and get a feeling of how… readable and maintainable it will be 6 months later. And it’s not too late. It isn’t yet a threatening mass of nonsense that makes me feel like starting over.
4. Sketching’s good. If I wanted to fit in every detail the day I write a feature, I’d spend less time designing and thinking about the structure of the code, and more time hacking pieces together. In theory, it’s never too late to refactor and always too early to over-design. In practice, putting water in our wine rarely hurts.

6 months after

Sharp. It’s been 6 months since the first Antistar release. I’ve just ‘cleared one of these lists’ and sneaked 24 bugs off it in the process (that is, I made a new list) – I’ll be ignoring the 24, trying at least – and worrying instead about putting some artwork together.

Then I’ll be looking at it, thinking this is it, and death-march cheerfully towards the next release.

Yay :)