Robert Peake on “Getting Software Done” [43 Folders]
This is a printer-friendly HTML version of Robert’s original posts for 43 Folders (Posts: 1 & 2)
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.
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.
Part II: GTD and Extreme Programming
I have to admit that I’m not a perfect adopter of Extreme Programming. We don’t program in pairs, for example — quite the opposite, our coders are flung far and wide, tethered together only by a broadband connection. However, as much as GTD is “advanced common sense”, so to my mind is Extreme Programming a form of “best practices on steroids” — and for this reason, there are not only many parallels, but great crossover when it comes to managing programming projects.
Software didn’t used to have to be very adaptable. Mainframe software systems were only slightly less mutable than the hardware they ran on, and dependability — not responsiveness, new features, or interoperation with some other cool, new application — was key. Along came the internet, and the ability to patch and change software online. All that changed.
Likewise, while even forty years ago dependability seemed to exist both in terms of job definition and job security, adapting to change may well be the single most important trait of the knowledge worker today. And increasingly, the ability to manage large volumes of information, focusing on what’s important and ignoring the dross, has become key. For this reason, a few critical concepts in programming apply to getting software done with maximum efficiency and also suggest some important directions for any kind of project — they are: regression testing, refactoring, and documentation.
Regression testing is, quite simply, spelling out a list of tests to perform so that you can verify that what you have created works as expected. The “regression” part of it is that you often want to run the same rudimentary tests you ran in the beginning of the project much later in the evolution of the product. This is to make sure you didn’t break something. Regression testing goes hand in hand with documentation, which stems from the same inspiration: describing how the thing should work. Once you have described how the thing should work, and made tests you can perform later to prove it, you need to make sure that documentation exists within the source code. In our case, we use automatic tools to pull out the documentation we mix in with our source code, and have created for ourselves an automatically updated manual of how various functions and parts of our system work. We even set up shortcuts so that with a couple keystrokes, we can access documentation for not only the core language, but our own collection of application-specific functions, right from within the source code we are working on at the moment. The result? Six months after writing something critical, I don’t have to go crawling back through file after file of source code to figure out how to use that particular building block or tool.
All of this relates to GTD when you bring in the concept of outcome-based thinking. Every time you pick up an artifact of your own thinking (be it a scribble on a note-taker wallet page or a mind map on butcher paper) and then decide that what you’ve really notated for yourself is a project, the very next question is: what is the desired outcome? In other words, how will I know I’ve finished this project? What will be the result? Likewise, all the activities in Extreme Programming such as gathering user stories, writing regression tests for each unit and component of the software, and documenting the intended behavior inside the code itself so someone else can later understand what you were trying to do — embody outcome-oriented thinking for software. Jumping to the end first works consistently and well to line up your thinking in the right direction. Getting that thinking captured appropriately into your trusted system — and not over-thinking into all the possible ramifications and rabbit trails that will likely only get blown away when new real-world input arrives — is key to staying agile, flexible, and dynamic.
Another key to programming in an agile way is refactoring. This is going back to what you’ve written — not to add features or fix bugs per se, but to clean up your thinking and make it line up with your new understanding of the project. The truth is that thinking takes time, and it evolves over time. So, revisiting the code on a regular basis, purely for the sake of shoring things up and reworking things into a more effective paradigm, may seem like a lateral shift on the surface — but makes a huge difference in the overall maintainability of the code. Likewise, the maintainability of your life and your trusted system that runs it can also be equated to how often you perform a weekly review. The weekly review is refactoring for life — a time to take stock, reevaluate your understanding of and progress on projects, make sure all actions are tied to projects and projects to actions, and to scrub out all the stuff that’s been either completed or rendered irrelevant by time (sort of like getting rid of the variables you thought you’d need in your code but didn’t — preventing memory leaks and tightening things up for later). Refactoring is as important in life as it is in software.
We used these three branches of Extreme Programming to great success in building GTD Connect. One other critical technique or skill involved was being able to flip from a very high-level creative brainstorming session with our senior people into sussing out the specific outcomes that would demonstrate we’ve done our job on the technology side. None of this precluded writing up documents spelling out our understanding of what’s important and what’s nice to have, the timing involved, as well as some of the mechanics of what we are doing and the business side of how much it would cost. But ultimately, being able to differentiate between and translate from the right-brain mind mapping sessions into left-brain outcomes led to just enough of a specification to get our coders excited. Trusting this process gives you the freedom to be wildly creative in the brainstorming session (because you’re not nailing anything down yet). It also empowers programmers with the flexibility to find a smart, dependable, architecturally sound approach to solving the problem on the other end — because when you feed programmers outcomes rather than dictating precise specifications in pseudo-code, you give them the freedom to work within the context of the whole system to come up with the best solution. And you leave room for constructive, creative surprises — the unexpected killer features that can only thrive in a healthy, outcome-oriented relationship.
One of the tenets of Extreme Programming Merlin mentioned in our panel is the idea that, “You ain’t gonna need it.” While I never overtly said this to The David in our sessions, the spirit of this approach is something that has pervaded the process of leaning into the great (and so far highly successful) experiment of launching Connect. That spirit of the idea is to build to a need, rather than a nice idea. In balance with this, we also tried to cast our net wide enough in terms of variety of features so that we can test and see what people gravitate toward, and what might fall away. This natural process of meeting customer feature demand on its own terms is highly analogous to the GTD approach of getting through each work day on its own terms, using action lists tied to projects rather than other forms of “best laid plans.”
A big key to the mechanics of getting a project as big as Connect done (and then maintaining and improving it incrementally) has been a shared project list accessible by all our developers. First of all, we trust our people. I have never seen the approach of trying to enforce people’s job constraints through software permissions really work when it comes to project management. Instead, anyone can add, edit or mark a project complete in our system. This means that our development people can keep their complete project inventory in a shared format and can edit projects assigned by others to keep notes and add important details. We use a Lotus Notes database for this, but this approach could also be easily implemented via one of many web-based applications or even a shared whiteboard if everyone works in the same room.
Another key with all of this, and a somewhat revolutionary approach, is that we don’t track bugs and feature requests in separate places. It all has to get done anyway. And because maintaining a comprehensive inventory of everything that needs to get done in one place, accessible by all the relevant people, we can very quickly re-calibrate to focus on what’s critical. Sometimes that’s a bug. Sometimes it’s a great new feature. Either way, we use the system to support us like a giant radar screen, and good communication in person, by phone, email, and IM to determine what’s critical and go after it. So far, it’s worked great to keep us engaged with our members and our own staff and be responsive to their input.
Connect has been a lot of fun to build, and it’s great to watch it start to really thrive. Hopefully this little peek under the hood has got your own gears turning about software development with GTD and perhaps even other areas of your work or life where these analogies hold. If you’re feeling particularly geeky, more platform-specific details on the best practices we drew from when pulling Connect together are here.
And if any of this has rung your bell and you want to chat, please drop me a line at robert at davidco dot com, or catch me on the forums. Until next time, happy coding, happy GTD’ing, and be well.
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.