Apr 28

Rael Dornfest

Rael Dornfest

Getting Apps Done (c.f. Getting Things Done)

Watching 37Signals building out their Backpack app-to-be and Danny O'Brien and Merlin Mann organizing up a storm for their rumored ;-) Productivity Hacks book for O'Reilly, I'm continually struck by the similarity of approach.

As Tim wrote in his "Designing from the outside in" post:

[37Signals] try to design the usability and function of the application first, and that drives the implementation. And if they can then extract a re-usable framework, all the better. For example, basecamp wasn't built on top of Ruby on Rails. Rather, Ruby on Rails was extracted from basecamp. This approach seems obvious and commonsense.

Terrie Miller, The O'Reilly Network's Production Manager, wrote in an email thread (excerpted by permission):

There's some sort of interesting intersection between things like BaseCamp and the whole GTD/43Folders/Productivity Hacks space. ... [T]he same people who are interested in how to manage projects using tools like Basecamp are also interested in ways to get all their stuff done using techniques like David Allen's "Getting Things Done" (GTD) workflow, hipster PDAs, or even Post It notes. ... I'm not sure what this grouping of concerns would be called (it isn't all online, it isn't all projects, it definitely isn't all management -- and maybe all of it lumped together is too big to be useful), but it feels like there's momentum behind it.

(Sampling of hyperlinks inserted.)

While David Allen's "Getting Things Done" meme has, over the past year or so, piqued the interest of alpha geeks left, right, and center, most I know almost immediately run into a bootstrapping problem. While Allen's system is carefully thought out and explained in his book, there's little real guidance for just how to work it into an existing iCal/ setup. For us hax0r5, it all gets very geeky very fast.

Both 37Signals and Danny and Merlin are chipping away at that bootstrapping problem: the former with their elegant applications and resultant frameworks, the latter with their (often inelegant but highly effective) hacks involving gem clips, note cards, and not a little bit of string. And in the process, they're laying down a set of design patterns applicable as much to getting things done as getting applications written.

In these days of highly-overwhelmed, information-soaked geeks, it's hard not to look to such quests with hope of some relief and (and, as you've no doubt noticed) provide them much link-love.

Aside: In the course of writing this entry I ran across -- utterly tangentially, mind you -- the following list of blog posts (listed in original reverse-chronological order):

  • Building of Basecamp
  • Custom 3x5 Cards!
  • Are you into XP Pair Programming - seriously?
  • Tools I Use

tags:   | comments: 2   | Sphere It

Previous  |  Next

0 TrackBacks

TrackBack URL for this entry:

Comments: 2

  laurence haughton [04.28.05 03:26 AM]

A new book on project follow through from the manager's perspective. The tactics that make sure what's expected gets done. Virtual press kit at Reach me at

  Rael Dornfest [04.29.05 03:30 PM]

I spent some time with JJ Jacobi at a Microsoft Research event last week and it turns out she's a GTD fan. Interestingly enough, she actually uses Xcode -- yes, the Mac OS X build environment -- as her memex (of a sort). She shared her reasoning, which I share with you (by permission):

Even though it wasn't perfect I decided I would use XCode as a preliminary GTD technology because:

* I was going to keep my GTD system on my machine -- but I didn't want to use outlook or palm. At the same time I didn't want to write my own tool before I got started. I wanted something I already had that made efficient use of display space while managing a lot of different files/data.
* I also needed a tool that allowed visual grouping of files -- a single unstructured long list of everything wasn't going to do. Xcode (or any IDE environment) can easily group files visually into the three bins (_incoming and ilk), project files, and finally reference files. The other nice side effect of using an IDE is that this listing is always visible.
* The embedded text editor made efficient use of a single window space
* Xcode would allow me to group all kinds of files (not just text files) into my GTD bins.
* I could easily reference past search results which was nice for finding tagged entries in the project files. (Like the next nextsteps)
* While Xcode wasn't perfect, it was good enough to use it for a while to decide what kind of functionality I really wanted.

The one area that didn't work out well was the reference file grouping. It was *very* nice to be able to quickly access my reference files, but it was too tedious to add them to xcode since it was a two step process (place in the file system, then link it into the xcode project in the correct reference area). I ended up deleting this bin from the xcode project file and just using the file system instead. This is functionality that I will add back either by creating a script -- or by moving to a more specific GTD tool I might cook up.

I pointed JJ at DEVONthink as it provides much the same interface as she's created for herself while affording simple drag-and-drop or drag-and-link into folders and text entries.

Post A Comment:

 (please be patient, comments may take awhile to post)

Type the characters you see in the picture above.