Sunday, January 23, 2005

Turning "Stuff" into Action

It's amazing how hard it is for me to write a well-formed to-do list, at least in terms of David Allen's "Getting Things Done" methodology. For example, for almost two weeks now my to-do list has included the items "Clean whiteboard" and "Clean office", and of course I've done neither. The whiteboard hasn't been completely cleaned in almost three years, in fact, because it contains a draft of an innovative information model for a business workflow system -- one based in small part, ironically enough, on some of the "Getting Things Done" concepts.

So, in order to clean the whiteboard, I first need to transcribe this model to paper or some other more enduring medium, so as not to lose the design notes, in case I ever get around to creating the damn thing.

To transcribe it, I need to figure out some place to put it where it's not going to get lost in a pile of paper, though. Otherwise, how will I ever find it when that magical day arrives that I actually want to start writing that program? After all, I even have the domain names already registered, so nobody can grab them before I launch... :)

...and that's about as far I ever get in the process of thinking about actually tackling that "clean whiteboard" task on my to-do list, which is a perfect illustration of how 90% of organization is half mental. ;)

I recently saw a nice summary PDF of the Getting Things Done workflow, and it illustrates certain of Allen's ideas a lot better than the diagrams in the original book. Specifically, it highlights two essential questions: 1) What is the successful outcome? and 2) What is the next action?

When I first wrote down "clean whiteboard", I thought that that was the successful outcome, and the next action. But it's not. The successful outcome is to have space on the whiteboard for new projects, while keeping an easy-to-find record of the things I already have on it. The next action would be for me to decide where that record is going to be kept, except that in the course of writing this blog entry I've figured that out, so the next action is going to be "get some paper" to write the stuff down on before I file it. Other stuff on the whiteboard (relating to PyProtocols, PEP 333, my PyCon presentation, and other miscellaneous projects) is probably going into my Ecco file on current software projects, so another "next action" in David Allen terms would be for me to switch over to my Ecco window and start typing.

The funny thing is, if I go down the various lists of undone things (either on to-do list or whiteboard), they all represent things blocked on making decisions of some kind. For example, I want to add pattern matching to PyProtocols' generic functions, but I haven't settled on a syntax or implementation strategy yet. Other things, I haven't done because they're a lower priority than some other thing I'm not actually doing, and it seems wrong to do them first, even if all this really means is that they'll be on the list forever.

(Allen's system would probably also designate most of my "stuff" as "Someday/Maybe" items, rather than active working items, anyway, so the very fact that I'm passing these things over is probably a good indication they belong on such a list.)

Anyway, the whiteboard thing is a good example of chunking up, or more precisely, not chunking down. I originally thought that "Clean whiteboard" was pretty darn specific and thought-through, but it really isn't. Maybe what I need to do is go back over these lists from time to time and ask, "what would I need to do before I could clean the whiteboard?" in order to make sure I've elicited the prerequisites. And if the prerequisite is something like "decide where to copy the stuff I'm going to clean off", then I can go ahead and make the decision, or at least determine what I'd have to do before making the decision.

In programming, I've been learning how to do the same thing; it's called test-driven development. Before you can actually code, you have to write a test, which is a concrete specification of what it is you're going to do. If you can't write the test for what you want, because there's something else missing, you make a note of the test you want to write, and first write one for the "missing" functionality.

It would be really nice if there were an obvious way to do that with non-programming to-do items, that would automatically ensure this sort of well-formedness checking. Maybe there's a way I can hook in a "mental routine" (to do the check) to that vague feeling I get when I look at something on my to-do list that I can't really do. After all, every time I looked at "clean whiteboard" in the last couple of weeks, my eyes just sort of slid over it to look at more "actionable" items. Maybe as a stopgap, I can write up some well-formedness questions on a post-it note.

Hm. Actually, the GTD workflow diagram already has a good way of phrasing the important question:

If this was the only thing you had to get done, what is the very next physical thing you would have to do?
The "only" part is really important for me, because it helpsavoid the complications I otherwise tend to impose, like relative priorities of other items. I probably shouldn't be prioritizing meta-tasks (i.e. the task of figuring out my tasks) anyway, and Allen's system actually forbids it, too.

Update: if you're going to clean an old whiteboard, it works much better if you spray paper towels and then use them to scrub, rather than spraying the whiteboard directly. The spray tends to run otherwise, and it's harder to concentrate it in the tough spots. Also, black marker seems much harder to expunge than other colors. Oh, and most important: make sure you (cough) have good ventilation (cough cough) before you (wheeze) start spraying!