listing problems instead of solutions

I’ve just noticed that one of my practices has changed subtly, probably sometime during the last six months or so:

I always keep a to-do list during each programming episode. The list begins with one entry, describing the goal I’m working towards. And as I read and write code, new entries are added to make sure I go back and fix or refactor everything I see along the way. Until recently, those additional entries tended to describe an outcome – “split class Foo to create Bar and Xyzzy”, or “wrap x and y into a Mouse class”, for example. But recently I’ve noticed myself tending to write entries that describe the problem – “class Foo too large”, “x,y travel around together”.

I have no idea how, why or when this change happened, but I’m pleased it did. Between the time I write a particular to-do item and the time I finally get around to executing it, I may significantly change the code in that area. Or I may learn something about the code and where it wants to go next. Or the problem may disappear, as a side-effect of some other change. Either way, the solution I might have on my to-do list has a chance of being inappropriate now that the code and I have moved on. So by listing the problem as I originally saw it, I’m giving myself a much better chance of creating the right solution for it – because I’m deciding on that solution in the presence of the full facts.

I’ve recently been re-doing a few kata that I first tried a couple of years ago. I’ve noticed that my results are dramatically better now, mostly I think due to delaying the moment at which I decide how to solve each micro-problem. This effect is an example of Mary Poppendieck’s “decide as late as possible” maxim. There are clear benefits in terms of the quality of my designs; and there are psychological benefits too, because I don’t have to spend time trying to remember why I wanted to do each item on the list. Everyone wins.

4 thoughts on “listing problems instead of solutions

  1. Firstly Kevin, thank you for your blog, I enjoy your writings a great deal.

    I have noticed a similar trend towards a to-do list of problems rather than tasks. My realization has come at a time in my career when I have just recently gone over the waterfall into the agile pool :)

    It does seem to be very “agile”; a focus on what needs to be achieved rather than how we feel it should get done.

    Kindness and please keep posting,


  2. Great idea! And very agile! I will try to implement it right away. I think I will change the name of my to-do list into to-solve, just as a reminder.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s