Matthew Mead

The Getting Things Done (GTD) weekly review is a key piece to Dave Allen’s Getting Things Done process. If you are not familiar with GTD, I’d highly recommend you visit Dave Allen’s company website. The weekly review is a weekly process to validate the information (things you need to do) in your GTD system is complete and accurate.

If you follow GTD you will learn quickly that a significant number of questions for GTD newbies revolve around the weekly review. And, in order for the GTD system to work and for the GTD practitioners to achieve a “mind like water” state, it is critical to trust that the GTD system contains everything that you need to do.

In order for the system to be complete, it must be regularly reviewed. Once you have a GTD system that you trust, and you are reviewing it regularly, it means you will automatically always know when you are doing the most important thing that you should be doing at that point in time (based on your physical surroundings). As a result, the weekly review is a critical activity.

I’ve been a GTD practitioner for about 2 years. Within the 2 years, I’ve had spans of time where I’ve been good about doing my weekly review…and spans of time where I’ve been pretty pathetic with my reviews. And, as I can attest, without regular weekly reviews, the system does not provide nearly as much value.

A friend told me about the Netcentric Outlook GTD Add-in about 1.5 year ago. At that early time in my familiarity with GTD, I tried the add-in but didn’t understand the value it could provide. At this point I was focused on the basic fundamentals of GTD and didn’t think I needed any fancy tool (and the $69 price tag turned me away too).

Late last year I thought I’d try the Netcentric Outlook GTD Add-in again (btw, I’m using Outlook 2003 on Windows XP SP2) to see if it would efficiently associate projects and next actions. In this second evaluation (with my head at another place and my GTD system pushing its limits in Outlook) I was very impressed by two features:

Ability to easily and painlessly link Next Actions to a project (key for weekly review)
Ability to create actions when processing emails in my in-box

The remainder of this blog will be focused on item #1 above and how it relates to the way I go about performing my weekly review. The GTD weekly review will be a bit personalized for different practitioners, but must contain the following:

A review of all projects and next actions (not necessarily all someday/maybe items)
A review of the prior week’s and the upcoming short and long-term calendar

The review assumes your physical and electronic in-boxes are empty and that all loose papers, notes, etc. have been processed. Finally, the weekly review may include a brain dump where you get everything out of your head (using trigger lists) and make sure there aren’t items missing from your system.

Reviewing the calendar is pretty straight forward, and if you are like me, you will typically find something that was planned on your calendar from the prior week that did not get accomplished for some reason. Or I’ll find something on my calendar that makes me realize I need to do something else…or there is a follow-on task to perform for the work I performed the previous week. And looking forward at the detail of my upcoming two weeks and a quicker scan of my calendar out about 6 months is pretty easy and quick to accomplish. If while examining my calendar I find something that requires an action or planning, I create the appropriate project and/or next action.

It is important to not do work while executing the review. This may sound ridiculous, but the temptation to just do some simple tasks (e.g. send an email) while performing the review is quite strong.

But reviewing projects and next actions is not so trivial. If you don’t have a system that ties your next actions to projects (and I didn’t for a long time) it is tedious and time consuming to know whether all next actions for a given project are in my system. My system currently contains 98 projects and 442 next actions (this does not include my 126 someday/maybe items). Of the 442 next actions, the bulk are associated with a project.

Technical Add-in Note: The Add-in works by creating an Outlook task for every GTD project and every GTD next action. The projects are put into an Outlook “Projects” category and project names are also saved to a special XML message (settings information) file that is posted in a Settings folder in your Outlook Inbox. The add-in has a mechanism to create new projects which takes care of creating the Outlook task as well as updating the add-in’s XML settings information. If you add a new Outlook task and assign it to the “Projects” category, it will not be recognized as a project by the GTD add-in. The proper way to create a project is to select “New Project” from the add-in’s “Open Projects” Dialog.

So the way I do my weekly review of projects and next actions is to first review all projects and their associated next actions and then to review next actions that are not associated with a project.

I start my review by choosing the Outlook task “Ordered Tasks by Project (GTD)” view (as displayed in the following diagram) to simplify the process of walking through all my projects and reviewing its associated next actions.

I review every project title, one-at-a-time, in the “Ordered Tasks By Projects (GTD)” view to see if any are not bold. Note that this view is created by the installation of the Netcentric Outlook GTD add-in and is not part of the standard Outlook installation. A bold project is good because it means that the GTD add-in recognizes the Outlook task as a GTD project.

Tasks that are not bold are bad because it means that the task is not recognized by the GTD add-in as GTD project. Any non-bold projects need to be promoted to an actual project in the add-in by double clicking the non-bold project (Outlook task) and once it is opened, selecting “Add New Project” from the GTD add-in as shown in the following screen shot. (Note: The reason I sometimes end up with Outlook tasks in the Projects category that are not recognized by the GTD add-in as projects is because I also manage my tasks via NextAction! on my BlackBerry 8800.)

When you open projects that are bold, the built-in Outlook task dialog is opened. From this dialog, click the open project button (highlighted in red) in the following screen shot.

The open project button launches a custom dialog (see below) that contains information about the project (in my example the project name is “Mitigate Radon”) and contains a list of associated tasks for the given project (my tasks are “Discuss timing of work” and “Seal basement floor/wall joint”). This is the dialog from which you can think about the given project and add (by clicking Add Task Action), edit (double click the row for the given next action task) or delete (open the next action task and delete it as you would delete any Outlook task) tasks as you see fit.

After I have reviewed all projects I then review next actions that are not associated with a project by selecting the task “Active Tasks By Project (GTD)” view. This view groups all next actions by project and creates two groupings of “none” projects. All “none” projects are next actions that do not have an associated GTD add-in project. Some of these next actions are someday/maybe items (which I only review about once per month), but the remaining next actions need to be reviewed weekly.

I review each remaining next action, one-at-a-time, in the “Active Tasks By Project (GTD)” view. I double click each next action to open the default Outlook task dialog. Sometimes the next action’s title, notes, priority, due date or category needs to be adjusted. Other times I realize what once was though to be a single next action really needs an associated project. And there are times where I need to delete a next action because it is complete. (Note: I don’t use the completed concept in Outlook tasks. Although it would be gratifying to see all the completed tasks, I feel completed tasks just create more distractions. So I delete tasks when they are complete.)

The weekly review can be a daunting task. I hope this information helps someone make their review a little easier. It still takes time and dedication, but once you get into a rhythm with the weekly review you can execute it faster because you know the content in your GTD system better. Once you regularly execute a weekly review, you are on your way to “mind like water”!

Software design patterns have been around for many years. And as most who follow design patterns know, they gained tremendous traction after Gamma, Helm, Johnson, Vlissides (these gentlemen are fondly known as the Gang of Four (GoF)) released their book Object-Oriented Design Patterns book.

What many don’t know is that design patterns have their roots in architectural patterns. Not architecture as in computer software or computer network architecture design, but architecture as in buildings and towns. Christopher Alexander coined the term “pattern” in the late 1970s in his writings. If you want to get into the heart of the origins of patterns, you can check out his original book The Timeless Way of Building. And his second edition (with additional authors) A Pattern Language: towns, buildings, construction. Although Alexander’s books are interesting from a historical perspective, they will provide little value in your pursuit of software design patterns while taking a large divot from your wallet.

So what are software design patterns? They are solutions to common problems that developers and architects face. Many software design patterns address common situations that developers need to implement in every application they build (e.g. object initialization). Take just about any programming problem and there are only a few good implementation approaches, but many bad approaches. Software design patterns capture the experience of experts in a form that others can reuse.

In the early 1990s, the best source for information on software design patterns was definitely the GoF Object-Oriented Design Patterns book. At my previous employer, we issued the GoF book to all new developers because the book defined a set of well thought through patterns but more importantly defined a new lexicon. The introduction and popularization of the software design pattern lexicon provided a common language for developers to express design options in a very concise manner.

The GoF book was revolutionary because it defined many core pattern names and provided details regarding the intent of the patterns and also included some code snippets to clarify the suggested implementation approach. Unfortunately, the code samples for the patterns are written in C++. Today, with a large portion of business applications being developed in Java, PHP and .NET, you may find the GoF book harder to consume than some more recent pattern books such as Head First Design Patterns for Java and Design Patterns for C# for .NET.

In addition, Martin Fowler’s book Patterns of Enterprise Application Architecture has been very influential. In his book, Fowler identifies new enterprise patterns and provides clarification and enrichment to other lesser-known patterns.

GoF defined four essential elements that are required for any software design pattern:

The pattern name is a handle we can use to describe a design problem, its solutions, and consequences in a word or two
The problem describes the context and when to apply the pattern
The solution describes the elements that make up the design, their relationships, responsibilities and collaborations. The pattern does not describe a concrete solution.
The consequences are the result and trade-offs of applying the pattern

GoF felt that a problem to be solved by a software design pattern must be seen repeatedly in practice to prove the pattern is applicable beyond the system in which it is first identified.

Patterns are typically divided into 3 categories:

Creational – like the name suggests, these patterns focus on factories and other techniques that help create (“new”) objects. Although the category sounds fairly straightforward, creational patterns are used in conjunction with dependency injection (sometimes referred to as inversion of control (IoC)) to help avoid unnecessary dependencies in your code which can help, for example, to make unit testing easier (i.e. ability to easily change factory implementation to facilitate stubs or mock objects for testing). The Singleton is an example of popular creational pattern.
Structural – as their name suggests, these patterns provide structure for one or more classes to achieve a certain objective. It is concerned with how classes are composed to form larger structures or subsystems.
Behavior – are concerned with the inner workings of classes such as algorithms and the responsibility between classes. Template Method is an example of a popular and powerful behavioral pattern.

Most patterns cannot be read once and completely understood. If you want to be able to use a pattern, you must approach pattern literature with the attitude that you will study the patterns rather than just read them. Some patterns have slight variations between different authors and sometimes slight differences in their sample implementation approaches. Sometimes these differences are a result of different technology platforms and languages. For example, patterns in .NET tend to leverage .NET platform-specific capabilities such as generics and delegates.

However, when learning a new pattern, the single more important take-away is to understand its intent. Otherwise, some patterns start to look alike and many patterns are implemented in a similar fashion by introducing an interface, abstract base class, level of indirection, aggregate object, etc. For example, in .NET the Role Object Pattern (ROP) and State Pattern are similar in their implementation. Both patterns start with a primary class that needs to either have a role or have a state. At first glance, especially by scanning their UML, they appear to be almost the same.

However, after studying their UML more carefully, their implementations are very different – primarily because ROP aggregates one or more roles that are reference by their Role interface and the State Pattern is associated with one state, which is referenced through an abstract base class. But the biggest difference is the intent behind the two patterns – ROP gladly exposes the role(s) from the class and embraces the concept of a role. To the contrary, the State Pattern hides the concept of a state class and just provides a simplified state value to its consumer.

Although patterns are meant to be implementation independent, most texts provide sample implementations. If you do most of your work in one programming language, you will greatly benefit by finding a resource on patterns that has accompanying examples written with your primary language. Even though you might be able to translate say from Java to C# you may miss some platform-specific features in C# during your implementation. For example, some .NET patterns are written to leverage .NET delegate (which are essentially function pointers to simplify threading) and the Observer pattern will leverage the .NET events/event handlers.

In future blogs I will address many GoF software design patterns and provide working samples in C#.

Technologist and Maker

GTD Weekly Review Using Netcentrics Outlook Add-in

History of Software Design Pattens