As the story dragged on

The main reason I decided to experiment with non user-visible stories was to keep stories short. That part worked great; as long as they were short, I breezed through the stories and was eager to start the next. But then one particular story — I'm looking at you, story 19! — turned out to be a lot more work than expected. As the story dragged on, I lost my motivation... and then it took even longer to get it done. I would like to avoid this situation in the future, if possible.

But how? By adjusting my process, of course! Ideally, I should be able to complete each story in one sitting; and now that stories don't need to be user-centric, there is no reason not to make them as small as needed. If they aren't, then the plan needs to be refined. Thus, this time, I am going to break something even more fundamental than the user-centric nature of stories: the fixed-length iterations! How naughty.

This iteration will end in one week, or when a story drags on for more than a day, whichever happens first. If it is the latter, I will have the opportunity to adjust the offending task, by dividing it into smaller chunks.


Alternatively, I could rethink my design so that the offending task is not needed, or vastly simpler. Or just different. Or more fun to code.

I mention this possibility because I stumbled upon a post from a writer explaining how she quintupled her productivity by optimizing her process, and she found out that she was more productive when writing scenes she was enthusiastic about. Well, I was enthusiastic about Story 20. And hated Story 19. I'm not sure why.

In order to figure it out, from now on I am also going to write down the best and the worst story of each iteration. Hopefully, a pattern will emerge. Although, to be honest, even if I had an easy criterion to distinguish stories which are going to be fun from those which are going to be boring, I don't really know what I could do with that information. Sure, some stories are less pleasant than others, but they still need to get done, right? Unlike passages in a book, if the code is boring to write, it doesn't mean the user won't enjoy the result. Who knows, maybe I'll find a different software organization which minimizes annoying tasks?


Iteration 5

As yet another crazy departure from conventions, I'm dropping story numbers. They haven't been very useful so far.

• Setup continuous compilation (using Substrate to detect when the source files change).
• Use signals to propagate errors.
• Implement an InputNode which can bake itself.
• Implement a Gui which links the input nodes with the input pane widget.