Anthony Panozzo's Blog

If you've walked by my area in the couple months or so, you may have noticed that I sometimes have a massive stopwatch displayed on my computer. I was consuming some content produced for the Agile 2008 conference, and came across a very interesting article about the Pomodoro Technique, a way to think about time and work differently. Staffan Nöteberg has a book about the system, and can probably explain it more coherently than my attempt in this post.

What is it?

The Pomodoro Technique is a system that Francesco Cirillo created and used when he was a student to help him focus. Staffan then used this technique successfully in software development, and believes that it can be applied to most things that people do. Pomodoro comes from the Italian word for tomato, which was the form of his original timer.

For the system, you just need a pen, paper, and a kitchen timer. I'm using this online stopwatch and using simple text documents to replace the pen and paper. The online stopwatch is nice because it has an alarm that rings through my headphones so I don't bother anyone.

How do I use it?

So anyway, a pomodoro is a set period of 20 to 35 minutes in which you focus intently on the task at hand. After each pomodoro, you take a 3-5 minute break to stretch, relax, or just kind of space out. Nothing mentally challenging should be done. When you do four pomodoros back to back, it's called a set. After each set, you should take a longer break (15-30 minutes.) This is an ideal time for lunch, running errands, making non-work related phone calls, etc.

OK, here's the plan. Anyone who wants to answer the following question with a comment is eligible for the prize. The winner will be chosen at random from valid, thoughtful answers starting on Tuesday evening. The prize will be your choice of:

• The Mythical Man-Month by Fred Brooks
• More Joel on Software by Joel Spolsky
• Peopleware by Tom DeMarco
• Rapid Development: Taming Wild Software Schedules by Steve McConnell
• Leaving one (and only one :) ) celebratory bragging comment saying that indeed, you are simultaneously a talented and lucky person

If you don't want to leave your full name, just make sure that I can get back to or identify you via the email you put down (which is not shown on the page.) I think this will be an interesting exercise to see where potential delays are and to start a dialog on where we can try to remove delays in our processes. The description talks about code, but your answers don't have to be limited to it.

I've recently been doing some ad-hoc testing at work, and it seems like my process could be improved somewhat. I'm tasked with testing a web application that I'm not exceedingly familiar with. At first, I am just going through the application with IE6 and trying out various functions or details and making sure that things look and behave appropriately with strange inputs. When I see something anomalous or a particular page that looks complicated or strangely laid out, I dig a little deeper and try to see what I can break. I figure that it's these sections that are the most likely to contain bugs. Taking screenshots of likely bugs has been helpful in entering them accurately into our bug tracking system and will hopefully avoid ambiguity in what I'm seeing for whoever tries to fix the bug, which will then require less communication overhead for me.

I heard Mike Kelly talk a bit about exploratory testing, and it seems like what I have recently been trying is similar to this technique. Essentially, exploratory testing is ad-hoc testing's bigger, more refined brother. Instead of just willy-nilly testing things, you have a designated goal and you create a plan that you try to stick to. When you see something interesting or have a clever thought on how to test that things are well done, you can venture off of the path for a bit and explore that idea. In this way, you can use your intuition as well as having a way to document and hold yourself accountable for the testing that you are doing.

Passing along some information from Mike Kelly regarding the 2009 schedule for the Indianapolis Workshops on Software Testing (IWST.) It's pretty short and dense, so I'll just copy from his blog (link no longer available):

We've posted the 2009 schedule for the Indianapolis Workshops on Software Testing. We're looking for people willing to share experience reports and people who just have a general interest in the various topics and would like to attend and ask questions.

Software development analogies are sometimes fun and potentially revealing. With that being said, I wanted to throw out a small nugget I thought of.

Growing up, I watched a fair amount of sitcoms until I realized the basic plot device. Essentially, something happens where a character on the show makes a choice, is worried about the ramifications of that choice, and is then somehow deceptive. They keep having larger and larger miscommunications and problems as the show goes on, and more problems (and hence hilarity), ensue due to keeping the problems under wraps. Eventually the characters realize the mistake, and the show ends with everyone having learned a valuable lesson.

• Note: I am not affiliated with any of the sitcoms mentioned below, nor do they support me financially. :)

Full House

At some point, I got pissed because I just thought "Why doesn't Stephanie just tell Danny Tanner that she wrecked the car instead of trying to hide it for like two more days? I'm pretty sure Danny's going to flip out and kick Comet and ground you, but at least you get it out in the open. There's definitely nothing to be gained from hiding it. Why would any rational person do this?"