WTF?? I missed something here?? I hope 43F does not intend to bloat content volume by publishing everything from every blog on the net.

“Part 2 of Robert’s article, entitled “GTD and Extreme Programming,” appears Wednesday on 43 Folders.”

Why? You have no “duty” to be good to your readers, but needlessly splitting things up like this is intentionally doing something that, while not really ultra-harmful, is at least “sub-beneficial” to readers.

It’s similar to the split “productive talk”. I’ve checked 43 Folders more frequently than usual lately, since I’m eager to hear the rest of it - but you could’ve just as easily given us the entire thing at one go.

Opposite of Calgary’s comment above, I see this as thinning out content volume.

Please reconsider this practice as it’s very annoying and makes 43F even more a timesink for all parts involved. I’m in the middle of seriously cutting down on my time spent browsing and this makes it harder.

Great aricle. Let the nay sayers say “Nay.” I’d rather get things done… I look forward to Wednesday.

What they don’t realize is that the two-part article system has been systematicallly engineered to be able to be speed read in less than two minutes. We tested it on thousands of gorillas (so like us!) and they all clocked in under 1:55.

Seriously — glad you liked the article. I’ll be lurking to respond to intelligent questions (and to ignore trolls) in case anybody wants to continue the discussion here.

When an article is getting too lengthy people (incl. me) will be put of by the amount of text. It’s the same thing with audio. In my humble opinion I think it’s great to split up articles like this.

I use netvibes.com to keep track of my RSS-feeds, so I know when there’s something new.

I’m a better programmer than GTD implementer. I’m curious about the “breadth-first” approach to webapps, and am hoping there will be a more concrete discussion of it. Does this mean the user doesn’t see what any pages look like until you’ve written almost the entire app? Or is it more a hybrid, i.e. do some depth-first, but still do breadth-first on the side you keep a sense of where you are? Hmmm, sounds GTD-ish…

I enjoy the small bites, so thanks for breaking it up. Eating the whole cow in one sitting is never comfortable. And I also appreciated the Peake article and think it fits fantastically with 43F. No bloating seen here. Thanks for sharing all your organizing fu.

I’m a programmer who’s into GTD. So for me, this is whatever the opposite of bloat is.

Not a programmer Fresh view of GTD Helps open my mind

So close, Wes — one more syllable on that second line, and it woulda been a haiku!

Crap! I had that extra syllable and forgot to type it. “A fresh view of GTD” I guess that was my sh*tty first-draft. BTW - the two-parter fits my attention span. Like I need to point that out.

Hey Rodney,

It’s no so much that breadth-first applies to web apps specifically. It’s that combined with a solid strategy, it makes for the best tactical management of just about any large project. You still have to know where you’re going, and still have to run down the trails to get there — but not overthinking the problem is a critical part of flexibility. Look for more on the convergence of XP (not the Microsoft product) and GTD tomorrow, and ping me if that doesn’t make it more clear for you.

Cheers, Robert

I would also relate the core concepts of GTD’s planning methodology to those of “Painless Software Schedules” [http://www.joelonsoftware.com/articles/fog0000000245.html].

The concept of the Next Action is directly analogous to the core philosophy concrete task selection:

“5) Pick very fine grained tasks. Your tasks should be measured in hours, not days. (When I see a schedule measured in days, or even weeks, I know it’s not real). You might think that a schedule with fine grained tasks is merely more precise. Wrong! Very wrong! When you start with a schedule with rough tasks and then break it down into smaller tasks, you will find that you get a different result, not just a more precise one. It is a completely different number. Why does this happen?

When you have to pick fine grained tasks, you are forcing yourself to actually figure out what steps you are going to have to take. Write subroutine foo. Create dialog such and such. Read the wawa file. These steps are easy to estimate, because you’ve written subroutines, created dialogs, and read wawa files before.

If you are sloppy, and pick big “chunky” tasks (“implement grammar correction”), then you haven’t really thought about what you are going to do.

…it forces you to design the damn feature.”

and, by extension, the concept of the Project vs. Next Action distinction is analogous to the feature vs. task distinction:

“3) Each feature should consist of several tasks. A feature is something like adding a spell checker to your program. Adding a spell checker consists of quite a few discrete tasks that the programmer has to do. The most important part of making a schedule is making this list of tasks.”

and the notion of living in the real world, recognizing what you are choosing NOT to do, to either schedule extension/feature reduction being hard constraints:

“13) A schedule is like wood blocks. If you have a bunch of wood blocks, and you can’t fit them into a box, you have two choices: get a bigger box, or remove some blocks”

Joel’s notion of a schedule is very depth-first/Big Design Up-Front, but, whether breath-first or depth-first planning makes the most sense for your project, “Painless Software Schedules” and GTD share this core philosophy of what distinguishes real/practical planning (Concrete, Next Physical Actions, grouped into Projects with clear Goals/Outcomes) — the difference is simply in how many next actions you force yourself to specify before beginning to act on them, which depends largely on how much you expect each project’s goals/outcomes to change over time.

jrk — good stuff. Check back tomorrow for more on the GTD-XP side as well.

Robert, I read pretty fast and I probably could have read both parts combined in about two minutes—it’s not the reading that’s the problem, it’s the context switching.

The network interface on my workstation is broken (and much of my work is completely non-computer-based, anyway) so I use an old computer (an iBook 2001 running Debian) just for net stuff - and I’m having problems finding the right amount of time to spend on this old computer.

It’s not just a quick “switch to browser window, press reload” for me—it’s a totally different context and it’s a context that’s more prone to procrastination that perhaps any other context—once I start Firefox I could lose hours. Setting a kitchen timer sometimes help, but I often forget, or “don’t think I’ll need it this time, I’ll just check email and a few sites” and time flies…

To summarize: Writing articles in serial is fine, posting several short audio snippets is fine—it’s splitting longer stuff up gratuitously (and I really want to emphasise that—the splitting seems to be done willfully as opposed to just by circumstance—and it’s split not just in separate files but also posted on separate dates) that bugs me. It gives me the impression (false impression as this might be) that it’s just in order to crank up the page hits.

It’s “Oh, I could’ve finished reading the article and then switch context, but it was a “To be continued”-piece… guess I’ll have to finish reading it tomorrow.” It’s an artificially created open loop!

As usual, Do What Thou Wilt; just be aware of this perspective, these two cents, when making your decision. It’s your readers, your fans, and their time.

(Yes, I do realize I come across as a total dweeb… but try to grok my point.)

Needless to say, I think the article is very good (or I wouldn’t bother at all!).

GTD saved my life (and interestingly, for me, GTD is like applying my programming practices—simple tools, comprehensive lists, clearly defined tasks—to the rest of my life).

Anna, the fact that you’re running a PowerPC port of Debian impressed me enough to want to reply. Merlin suggested splitting my precious baby into two parts, and little did I realize it would ruin your day. But remember: it’s not an open loop if it’s in your trusted system. Tomorrow’s article will come out around 8-ish, and so if you’ve committed to reading it and want to be the first to post a witty rejoinder, you could calendar that as hard landscape for, say 8:15 (on Konsole or Kontact or Gnome Calendar or whatever it is you use). Otherwise, since the article will be around as long as 43Folders is around (centuries, at least) you could put it in your @FunkyCoolLaptopOnline context to do whenever you like. Glad GTD has helped, and glad you liked the article. Hopefully part two will prove worth the wait!

I’ve been a programmer, teacher and coach using Extreme Programming(XP) for about 7 years now and the main appeal of GTD for me is it brings that sensibility into the rest of my life.

GTD really is like XP for physical stuff.

In the absence of an updated book, I’m really hoping for more stuff like this - GTD for Geeks.

[…] Productivity, Career & Personal Development Get Some Sleep - Part 3 DavidCo’s Robert Peake on “Getting Software Done” (part 1) DavidCo’s Robert Peake on “Getting Software Done” (part 2) […]

I like this idea but I believe the tools out there today do not support this type of development. I have wrote a little further about it at http://www.wrightin.gs/2006/10/gtdapproachto.html.

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?

Hi Mike,

Thanks for your thoughts and questions. I agree that the actual mechanics of writing code are largely parent-child (i.e. linear) in approach. The point is to “cover your breadth” (a bit like covering other things) by having a complete inventory of projects and their next actions (i.e. one parent and one child) in a trusted system that’s easy to input into and easy to pull from, scan down, and select tasks from by context. This ensures you don’t lose the forest for the trees.

I think the other side of this is to be flexible in your approach. So many programmers I’ve seen tend to want to latch on to GTD as some kind of system requirement for life. It’s a lot mroe than that. For example, when I’m wearing my programmer hat, I don’t necessarily go back to my list to write down every subsequent emerging next action once I’ve knocked one out. Due to the highly sequential nature of coding, the overhead incured by having to write something down in order to do it just doesn’t make sense. The point is to have a reasonable bookmark in time on each of your projects, and if you slip behind and get interrupted the worst that happens is you have to re-think a little.

The system is yours, and should line up with your reality. What GTD brings to programmers is the opportunity to turn a risk-frought and brittle linear approach into a more flexible, agile approach to life. That’s what breadth gives you.

Hope that helps. It’s sure helped me.

Cheers, Robert

[…] Guest Post: DavidCo’s Robert Peake on “Getting Software Done” (part 1) | 43 Folders (tags: programming gtd software development process) […]

I don’t know if I can handle any more convergence between 43F, Joel, and XP practices… :)

Artificially open loops annoy me too, but 10 mins is already kinda long for me to listen to a podcast. I usually end up having to rewind a bit b/c I opened something else while listening. That’s not your problem though!

Hey Merlin — is it time to put the mindfulness puppy back on the paper? It sure is in my house. Give us some mindful lovin’ when you get a chance.

[…] This is the second of a two-part article by Robert Peake, CTO of the David Allen Company. Be sure to start with yesterday’s first part, “Why GTD Matters To Programmers.” […]

[…] Well, looks like even the man (or rather, The David) himself applies GTD to the software process (or more accurately, his CTO does). From 43Folders we have a two part series on the sbuject of “Getting Software Done” (part one) (part two). […]