Thursday, May 20, 2010

Learning the Pomodoro technique

During a workshop of Francesco Trucchia I've been introduced to the Pomodoro technique for time management. I've known the existence of this methodology for years, but I never gave it a shot, being unsure if it was adequate for programming tasks.
It seems however that in the Agile world the Pomodoro technique has a good following. I won't go into the details of explaining this technique as the official site can do this much better than me (I started timeboxing with pomodoros on Tuesday morning.)
Basically, the atomic unit of time is an uninterruptible pomodoro, which lasts 25 minutes and which comprehends 5 minute pause at the end of period of work. Pomodoros can't be sliced up nor you can do other tasks different from the planned ones during a pomodoro, and the pause of 5 minutes is mandatory. During the pause, you can't continue thinking about the problem you were tackling (this has been difficult to grasp, but if you clear your mind during a pause 5 minutes have a value of much more).

Timeboxing has been very useful for writing articles, which is a task that commonly can suck up hours. I got a feedback on how much I was completing, and been forced to improve my process and avoid distractions (like looking for a word on Wiktionary or insisting on a particular construction).

For programming, which is the critical task, I am still experimenting after three days. With fast computers or platforms, this technique works very well. But sometimes I work with Java and I can get a cup of coffee before a test finishes running. I can't help multitasking with two machines to get something done in this environment.
The most difficult part for now has been estimating, since I have no experience with these short timeboxed. However, these estimations may become more accurate than
The rapid feedback of a pomodoro finishing is definitely a psychological pro, since it gives me back confidence on the task I complete and notice me if something is scattering into the next timebox (and so may be re-estimated, or maybe I should take a wider look at documentation before jumping into coding).

The forced interruption, in fact, has proven very useful, despite the worries of interrupting the flow.
First, Test-Driven Development helps me keeping my flow when I resume my work. I take a look at the last unit or acceptance test that does not pass and I know immediately where I was working on.
Second, it is often the case that I'm taking too much time on a single task: for example I am perform fine refactoring on code that I may end up throwing away, or I am insisting on integrating an external library now and fighting with runtime errors when I should switch to a different task with higher ROI.
Thus, the basic 25-5 minutes cycle is not a danger for programmers. Enter often in a state where we lose track of time it's not something we should be proud of...


Jonathan Nieto said...

Hey Giorgio,

The same happened to me, sometimes without realizing I enter to the dark hole of refactoring code that may be wasted.

Even though, what happens when you have some tasks that require much more than 25 minutes to be completed, like a module when you need to conserve the same ideas and finished it before moving on?

Giorgio said...

When you have a long task to accomplish, you schedule more than one pomodoro for it. The mandatory 5-minute pause is part of the vision of the Pomodoro technique, since its purpose is to keep your mind fresh and preventing losing more than 25 minutes in the worst case: when a Pomodoro rings you interrupt your work and when you return to it you're unlikely to continue to refactor *everything*, something that can happen when you lose track of time.