Robert Peake is the brainiac CTO for the David Allen Company (a/k/a, "DavidCo"). I first met Robert when I was down in Ojai a few weeks ago to record some stuff with The David, including our Productive Talk podcasts and that TechGTD panel we did with Robert and Eric Mack.

Robert really impressed me with his humor, his insight, and his mad Macintosh skillz. Also -- off the record -- I happen to think Robert's probably the most articulate evangelist for geek GTD I've ever met. He really gets both pieces so well that, of course, I demanded he write an article for 43F, right on the spot. He was kind enough to play along, and flipped around this terrific piece in record time.

As he covers in this series, a lot of Robert's time over the past few months has been spent putting together the GTD Connect membership program, as well as making sure all the company's lights stay on from a technology standpoint. Since I know a lot 43F readers share Robert and my interest in GTD and programming, I'm sure you'll dig hearing from him. He successfully pulls together some pieces I've had floating around in my own head, and I thank him much for sharing this.

[Note: Part 2 of Robert's article, entitled "GTD and Extreme Programming," appears Wednesday on 43 Folders.]

Getting Software Done

by Robert Peake, David Allen Company

Since launching GTD Connect, we have gotten a lot of great feedback not only on the content, but on the technical underpinnings of the system we built to deliver the audio, video, forums, podcasts, and other goodies on the site. What a lot of people may not realize is that, to my mind, a lot of the elegance expressed in the technology that drives Connect stems from the fact that we implement and use the GTD methodology in our software development process. We really do "eat our own dog food" at DavidCo, and I'm convinced that necessarily translates to a more positive user experience overall in every product we produce, and especially software. A lot of people also don't realize how highly relevant GTD is to the software development industry specifically, and how many interesting parallels there are between software best practices and workflow best practices (i.e. GTD).

So, I'd like to run through some of the relationships between GTD and developing software well, using the past eighteen months or so of building up GTD Connect from concept to reality. I'll use our experience building Connect as a kind of case study to ground some of the concepts and ideas with practical examples. Having seen a range of tactics deployed in software development by other companies, I can definitely say that our outcome-oriented, GTD-inspired approach to building out the web applications that make GTD Connect work has been far and away the most functional and positive approach I've encountered so far. So, if any of these tips and tactics strike a chord with you, I encourage you to consider looking at how you might fold these concepts into your own project management -- whether or not the project is software.

Part I: Why GTD Matters To Programmers

The first myth to dispel is that programmers don't need GTD. The Orwellian (or perhaps even Kafkaesque) world in which a programmer is nothing more than a human vessel for translating detailed design specifications into lines of code -- left to right, top to bottom -- is nothing more than a nightmare. The waking reality is that programmers in functional development companies make complex decisions and juggle multiple priorities constantly. And don't even get me started on interruptions. I have seen so much time, energy, and cash sunk into complex Gantt charts that get obliterated with the flick of a CEO's finger. Any company that thinks A,B,C priority codes and strap-on horse blinders for their programmers are effective means to stay on the leading edge of software is headed for a rude awakening.

Permit me, if you will, to borrow a few pages from computer science for a minute to illustrate the power of GTD in the programmer's world. The term "serialization" can refer to a process of basically freeze-drying data into a format that can later be reconstituted and played with elsewhere in the program. It's a very powerful technique for maintaining the state of the data, intact, as you transport it to another location (physically, virtually, whatever). Using a trusted system with the GTD methodology allows you to serialize your work life -- to freeze dry it in a readable format (your system, be that a Hipster PDA, a plain text file, or a fancy graphical task manager). By effectively bookmarking your complete working state just enough so that you can pick back up where you left off, GTD actually allows you to deal with the boss that comes in every five minutes to get an update on your TPS report cover sheet. The promise of a trusted GTD system is the promise of never having to think twice about what you were doing; just as the promise of serializing data is that you don't have to re-instantiate or re-calculate the structure you serialized. Store it, retrieve it, add water, and poof -- you're back up and running without any wasted cycles.

You can also handle massive changes in the architecture of the software you are working on -- whether that's coming from inside your company or via a customer -- because the beauty of the GTD system is that it deals with ambiguity in real time. The analogy I use here is data search trees. If you imagine a tree with many branches, the depth-first approach to searching the tree would be to go down to the end of every branch and back again. The breadth-first approach just involves checking out all the junctures on one level, then the next. GTD is a breadth-first approach to handling your life. Rather than trying to run down all the branches to the end, using GTD means thinking just as far ahead as you need to think in terms of your actions, and no further. So when things change in the real world, as they invariably do, you don't have to spend hours re-drawing the Gantt chart -- instead, you are already at the appropriate juncture, and can instantly re-calibrate and change course to take the next most appropriate path. This means you are constantly thinking at the level where the surprises really happen, rather than building out into the future on a potential house of cards. For risk mitigation, as well as remaining in step with an evolving understanding of complex projects, this is huge.

GTD in this way also provides the ultimate "safety net" for making sure stuff doesn't slip through the cracks. Sure, the act of programming in itself is highly linear: you run down the path until you have satisfied your test cases, then you move on to the next thing. However, in addition to bookmarking your progress along the path so that you can get right back to what's important after an interruption, GTD also gives you a complete, trusted inventory of all of the very next steps along all possible paths. Combined with an overall strategy (obviously), this means you can program with greater confidence and peace of mind -- can run down the trail knowing it is the perfect trail for you to be running down at this moment -- because you have scanned all the other options first, and know this course to be the best. Life, especially the life of a developer, is an open-ended, unknown tree. And the breadth-first approach of GTD is necessarily the most efficient option for traversing that tree.

For the old-timers in the crowd, a much cruder form of outputting data from the running program in a storable format is the famous core dump. So named because originally magnetic cores stored the ones and zeroes involved, this process is the software equivalent of downloading your entire brain into a file. Wouldn't that be nice? The "mind sweep" component of GTD is just that, and in fact David has often referred to it as a kind of core dump for "psychic RAM." This is how you periodically check in with your own brain to see what is holding your attention, and get it out of there to look at. This is how you assemble those lists of possibilities (projects and next actions) that serve as the safety net to give you confidence that what you are doing is the right thing to do, and combined with the two-minute rule and next-action thinking, gives you that freeze-dried bookmark of your working state so you can seamlessly pick up where you left off when (not if) you get interrupted.

Clearly, programmers need GTD more than Jolt or Domino's. And the people managing programmers, responsible for architecture on the front end and quality assurance on the other side, need it just as much. Permit me to explain...

[Note: Part 2 of Robert's article, entitled "GTD and Extreme Programming," appears Wednesday on 43 Folders.]

Robert Peake used to teach programming languages to computer science students at Berkeley before earning his degree in poetry. These days he is the CTO of The David Allen Company, where he reads, writes, and thinks about many things in many languages.

Update 2006-10-18 10:05:52 - For your convenience, here's an easy-to-print HTML version of both of Robert's posts.