Interesting stuff. I’m a bit puzzled by the breadth first approach as well though. When you’re writing software efficiently (well at least when I’m writing software - maybe I’m a freak) you need to do two things. Number one is to get into the ‘zone’. Number two is to build a mental model of the structure and context of the code you’re working on. The two combined give a delicate yet really powerful connection to the task at hand. It takes a while for most people to get fully into this state but it’s really worth making some kind of effort to do so.

My projects (in the GTD sense) are almost always tree structured and the closest relationship in a tree is between parent and child rather than between siblings. If you take a breadth first approach to processing your GTD project tree’s next actions (the leaves of the tree) then each time you switch to another next action you’re taking a much larger contextual step than if you start from a leaf and work back up the branch as far as you can before moving on to the next leaf.

I find I really struggle to get any rhythm and focus if I’m always context switching like this and I think it’s the biggest weakness of GTD. So far I’ve not come up with a way to get a list of next actions prepared up front and yet still be able to process them sequentially without having to keep moving up the tree after each one is done.

Perhaps it only applies to GTD in relation to software development but I’m generally not convinced by the old ‘software development is a unique case’ argument. Does anyone have any tips on how to handle this?