An apologetic rationale for David Allen’s “Getting Things Done”

When I commenced my PhD studies in September 2011, I decided to replace my existing system of personal organization with a new, much-talked about system referred to as Getting Things Done (GTD). This is, in fact, the main title of a book written by David Allen and published in 2001. Therein, Allen describes a personal organization system which purportedly increases productivity in a stress-free manner. (I’ll succinctly summarize the main points of that system below.) I write “purportedly” because it is in my nature to almost always assume a skeptical position (in the sense of rationalism) when reading and examining a particular matter. In other words, I focus only on the facts of the matter.

Yet, Allen’s writing is based on an experientialist approach wherein the phrase “trust me because I’ve seen it” seems to be clued at incessantly throughout the flow of the book. (In fact, at some point, Allen does write: “…but in the meantime, trust me.”) Thus, I wondered, could there be any scientific (neuro-psychological) rationale behind the foundational claims of superiority of such an organization system? Well, I didn’t find a plausible answer to my question until I came across Mihaly Csikszentmihalyi‘s seminal book “Flow.” It is my intention to elucidate on that answer in this post. At first, I shall illustrate Allen’s GTD system along its structural points. Next, I shall attempt to use some psychological results from Csikszentmihalyi’s work to rationalize (at least to some degree) some, if not all, of Allen’s points.

To motivate the reader into his system, Allen introduces the concept of “incompletes” or “open loops” (pp. 12–15), which entail essentially stuff (thoughts, ideas, intentions, created or discovered information) that one has in mind that is occupying one’s mind. This stuff (or, commitments) need to be thoroughly identified (for one may not be fully aware of all of them) and manifested into some sort of tangible system (electronic or physical) so that one may then take the necessary action(s). Thus, the basic principle behind the GTD framework is to collect and corral all the stuff that bugs your mind and decide whether and how to act on it. The trick to effectual organization is to keep reminders about such actions and consult (review) them frequently so one doesn’t miss doing any “incompletes.” Furthermore, on pages 15–17, Allen discusses on why “incompletes” are on one’s mind. In particular, he states: “Until those thoughts [incompletes] have been clarified and those decisions [to act on them] made, and the resulting data has been stored in a system that you absolutely know you will think about as often as you need to, your brain can’t give up the job” (p. 16). It is exactly the latter conclusive statement that I intend to apologetically rationalize here.

Allen’s Getting Things Done (GTD) system comprises five phases:

1. Collect. One must always collect everything that is deemed as an incomplete in one’s mind. Every thought, desire, intention, extravagant idea or opinion that has a “…’should,’ ‘need to,’ or ‘ought to’ attached to it” (p. 26) needs to be expelled from the mind and written down somewhere outside the mind. On page 29, Allen allegorically states that one’s mind is like a computer’s RAM — it can only hold and process that much. Thus, one needs to “get it all out of one’s head.” Naturally, getting them out is not sufficient and efficient unless one processes them, which brings about the next phase.
2. Process. Now that one has their stuff out of their mind, one needs to process what each manifested item means. Allen provides a nice, intuitive flowchart of this “algorithm” of his on page 32. In simple terms it works as follows: Take an item from your system and ask yourself what you can do about it. That is, what’s the next physical, unitary action you can take to do that item? If there is no action, trash it or incubate it for prospective use. If there is an action, determine what it is and if it takes less than 2-3 minutes, do it; otherwise, put a reminder somewhere in your system to do it in due time. How does one organize reminders, though? That’s the next phase.
3. Organize. Here you want to separate actionable from non-actionable items. The latter can either be trashed if they have no value or incubated/referenced otherwise. The referencing should be general (e.g. file-folder-based). Actionable items posit a gimmick: if an incomplete you’ve taken out of your mind takes more than one action step to complete, then Allen refers to it as a project. Thus, you can’t “do”  a project, but you can only “do” the actions associated with that project. For instance, if item “Save the world before I die” was on your mind and you took it out, it most certainly needs more than an action step and is, therefore, a project. Allen advises one to keep projects in a separate list and the actions associated with them in another list for frequent reviewing, which yields to the fourth phase.
4. Review. Now that you’ve organized your stuff, you must review them so that you actually do them. Reviewing starts from the most exigent element — the calendar — and proceeds with the next actions that you intend to do. Also, a weekly review of all you’ve got (including your list of projects) is essential to keep your system up and running.
5. Do. The final phase of Allen’s GTD system is to actually do things, mainly based on your intuition, but also on the contextualization of your settings. For instance, if you’re on a plane using your laptop, you’ll most probably do things that can be done only on your laptop (e.g. email, write a poem, etc.).

The rest of the book goes at length to describe the actual implementation of this system and to get projects going through several tricks and tips based on the author’s expertise as well as on other practical knowledge.

Now, if you look back at the most vital point of this five-phase system, the first point, you  might naturally ask: Why is it that one needs to get things done by first getting them out of their minds? That is, why won’t the brain give up the job? Why would one want to free up one’s psyche of stuff that bugs one? What’s the rationale behind this? Should I just trust the author and invest my time in implementing a system of personal organization with utter skepticism and risk to end up not leveraging it? These questions were sitting at the back of mind as I was reading and implementing Allen’s GTD system. These questions were the only “open loops” that thwarted me from assembling the system back when I finished reading the book months ago. But I answered them comfortably as I was reading Csikszentmihalyi’s “Flow” and I can reassure you that after implementing GTD with less skepticism it does work smoothly, overall. Here’s why.

The essence of Csikszentmihalyi’s “Flow” is about positive human experiences that enable one’s life to flow, i.e. to be exhilarating, vivacious, enjoying life, and so forth. Csikszentmihalyi (whose name sesquipedalophobics might want to eschew pronouncing) provides rigorous psychological arguments (based on decades-long research) on what flow is and how to attain and preserve it using a phenomenological, rather than anatomical/biochemical, approach to the functioning of the nervous system and the mind.

After revisiting happiness in the first chapter, Csikszentmihalyi elucidates on the anatomy and limitations of consciousness interestingly in light of the information-theoretic concept of entropy (p. 25). On page 24 he writes: “A person can make himself happy, or miserable, regardless of what is actually happening ‘outside,’ just by changing the contents of consciousness. [...] To develop this trait, one must find ways to order consciousness so as to be in control of feelings and thoughts.” According to the author, information theory is relevant to apprehend what goes on in one’s mind through such a model of consciousness. This could be a valid undertaking because after all: “The function of consciousness is to represent information about what is happening outside and inside the organism in such a way that it can be evaluated and acted upon by the body” (p. 24). As such, consciousness may be construed as the central “clearinghouse” which handles sensations, thoughts, intentions, desires, etc. Note that intentions are what provides and keeps order in the consciousness (p. 27). And these intentions are organized in a hierarchy of goals/outcomes (p. 28). Hence, we can freely control which outcome to pursue based on our subjective prioritization of objectives. In David Allen’s sense, these outcomes could be viewed as project outcomes, but also as the next actions to take to do whatever incomplete has been collected.

But consciousness has indeed a major limitation: it can process only that much information. The empirically observed terminus of the amount of information consciousness can process at a time is at most 7 bits. The mind can discriminate these 7-bit chunks at every 1/18th of a second, which implies that an average human can process roughly 120 bits of information per second! If we assume that a human is awake (“conscious”) for 16 hours a day and lives on average 70 years, the lifelong amount of information the mind can maximally process is roughly 185 billion bits (p. 29). Pretty fascinating, yet quite minute compared to infinity!

To understand what this limit on the mind’s processing power implies think of the following scenario: If it takes a person 60 bits of information to comprehend what another person is saying, then theoretically one could be listening to two persons at the same time and understand both of them readily, since the total processing power of the mind is 120 bits (per second). But we all have experienced such a situation and we all are aware of the practical impossibility of such a (stochastic) event. The reason this is not practically possible lies in the fact that one’s consciousness is already occupied with existing thoughts, feelings, “incompletes” or “open loops”! Consequentially, if one liberates one’s mind by controlling one’s consciousness, then one could achieve flow. It exactly this conclusion that supports the ostensibly efficient system of personal organization put forth by Allen. In other words, if one frees up the mind by means of controlling consciousness (the processing unit of information), then one gives it the chance to process even more information (discovered or created), which one wouldn’t otherwise process.

In Csikszentmihalyi’s words, what Allen refers to as “incompletes” are, as a matter of fact, ” things that occupy the mind and reduce its capacity of processing information” (p. 30). This brings about the discussion on attention, whose intentional ordering of consciousness averts increased (psychic) entropy, thus reducing the chances of yielding disorder in the mind. On page 31 we read: “It is attention that selects the relevant bits of information from the potential millions of bits available. It takes attention to retrieve the appropriate references from memory, to evaluate the event, and then to choose the right thing to do.” Hence, learning where to direct attention to implies controlling one’s consciousness. This means that one’s personal productivity could be flowing incessantly if one induces order in one’s consciousness. This is exactly what David Allen alludes to throughout his GTD book. (“The Art of Stress-Free Productivity” is, in fact, the book’s subtitle.)

In all, “The mark of a person who is in control of consciousness is the ability to focus attention at will, to be oblivious to distractions, to concentrate for as long as it takes to achieve a goal, and not longer. And the person who can do this usually enjoys the normal course of everyday life” (Flow, p. 31). Thus, if we can at least control what we want to get out of our brains and efficiently manage it through a working, actionable organization system, we should attain not only flow, but also professional productivity. Based on my preliminary evaluation of the GTD system, this has been indeed the case in my professional and academic life.

The main point to remember here is this: The reason why Allen claims you want to get things out of your brain is  what Csikszentmihalyi concludes: to free up (or at least attempt) your mind so that the information-processing power of your consciousness increases. If you (learn to) control your consciousness by steering attention attentively, then you bring about order in your mind (increased psychic energy). And, thereafter, flow comes into play and psychic entropy dissipates. Flow, in turn, provides for a stress-free life, which consequentially yields efficient personal productivity through an effectively implemented organization system, such as Getting Things Done. But the prime step to take is to collect and corral incompletes in one bucket, whence processing, organization, reviewing, and doing follow. I highly recommend the reader studies both books, especially Flow.

As a side note (to myself) I must confess that while reading and studying both books I observed patterns that were always present in my life, but which I could not eloquently articulate at least to myself.

Computer-Supported Collaborative Work; or, my first PhD course

Throughout my academic experience, there is only a fistful of courses I valorized. The Computer-Supported Collaborative Work (CSCW) course I attended at UVic and taught by M.-A. Storey in the September 2011 semester is one of them.

The course was divided into three parts. The first part, spanning roughly four weeks, consisted of lecturing and blog posting. I found the latter to be quite beneficial in terms of gaining background knowledge in the field. We were assigned weekly readings (quite challenging and instructive); we were asked to blog on them and we would discuss them the in following class meetings. (In fact, what instigated this blog is the posts I wrote for the CSCW course blog!)

In the second part of the course, the “dive-in” section, we were supposed to organize student-led workshops pertinent to the theme of the course. We formed four groups comprising graduate and undergraduate students with a group having no less than four and no more than six students. We chose a topic amongst a pool of previously brainstormed topics and we had at least a month to organize and prepare for the workshop. My workshop was on e-Government and ran on November 1.

The third and last part of the course was about hands-on demonstration of the scientific concepts we gained in the first part and the manifestation of CSCW-compliant systems. We were also asked to keep a lab book of our activities. This part culminated in a final report and presentation on December 6. My project involved conceptualizing and implementing an awareness-providing visualization tool for collaborative software development. More on the tool can be found in my other post here.

Contemplating retrospectively, these three parts posited unique challenges and problems that required fast and efficacious solutions. I love to read and I thus fell in love with the first part of the course. I love to write and I thus enjoyed contributing to the course blog. I love to collaborate with others and I thus relished organizing and contributing to our workshop. I love to do research and to humanize results and thus I enjoyed the third part of the course.

I’m looking forward to attending similar courses in the future. I’m pretty stoked for the January 2012 Global Software Development course I’m taking with my supervisor, Daniela Damian! More on this later on…

ProxiScientia: A sneak preview of a visualization tool for collaborative software development

The September semester is officially over, at least for me. This was my first semester as a PhD student, too. And it could be construed as a test of my patience  in assuming various challenges or challenging tasks and the success rate in attaining the predefined objectives, if not more.

I confess I did, in fact, accept to TA two third-level undergraduate courses while taking a peculiarly interesting, but challenging, course known as Computer-Supported Collaborative Work (CSCW — could it be!) taught (or, rather, facilitated) by Margaret-Anne Storey. More about my contemplations on this course can be found in this post. Here, I’d like to discuss on the project I completed for the course which culminated into a final paper and presentation in lieu of the traditional, prosy final examination-like course structures.

Basically, the project I chose to pursue along with Sean Stevenson of CHISEL and Owen Duckett (an undergraduate student here at UVic) involved conceptualizing, designing, and implementing a visualization tool that provided real-time awareness of ongoing activities in a collaborative software development environment. We baptized this tool with the name ProxiScientia, a portmanteau word merging “proximity” and “scientia”, the latter meaning “awareness” from Latin. The backbone (and back-end) of ProxiScientia is Blincoe et al.’s proximity algorithm, which has been accepted for publication at the CSCW 2012 conference. (Getting a hold of such oblivious unpublished information required less than a cloak-and-dagger operation, mainly thanks to modern networking techniques…)

Let me succinctly expose the conceptualization of ProxiScientia in terms of a solid five-dimensional framework proposed by Storey et al. in this paper:

1. Intent. The motivation behind ProxiScientia lies in the needs that arise to efficiently coordinate and communicate in collaborative software development environments in real-time. Visualizing such requirements posits a strong cognitive support to developers, testers, documenters, and even project managers.
2. Information. ProxiScientia is based on the proximity algorithm, as mentioned above. This algorithm extracts context data, i.e. data that captures the user’s interaction with their IDE. Because user-IDE interactions occur continuously, proximity captures them in real time, which is essential per our tool’s intent. ProxiScientia, therefore, does not carry out semantic analysis on the source code.
3. Interaction. This dimension is crucial for the visualization as it outlines how the user shall interact with the tool. ProxiScientia may be integrated into the IDE as a plug-in or it may serve as a standalone  system. It shall convey information to the user silently or disruptively. The latter could pose a disruptive interruption threat to the user’s prospective memory; however, we believe that the information thus provided far outweighs the importance of most future tasks because immediate coordination in collaborative projects is vital with respect to the overall project objectives. (Or, so says empirical research in the field… I believe it, epistemologically.)
4. Presentation. ProxiScientia uses entity-centric radar graphs or networks, wherein an entity represents a developer or a task. In the developer-centric case, the current developer is placed in the center of the graph and other related developers (yielded by the proximity algorithm) revolve around as nodes. The distances between the revolving nodes to the central node represent the proximity semantic relationship. The same principle applies to task-centric graphs (screenshots below).
5. Effectiveness. To determine the effectiveness of ProxiScientia, we plan to conduct rigorous, in situ user studies. Preliminary expert opinion studies have revealed encouraging results and have provided invaluable insights to ameliorate features and other technical properties of the tool.

The following figure illustrates ProxiScientia integrated as an Eclipse plug-in and tested on some dummy task with simulated users:

ProxiScientia as an Eclipse view-part plug-in (Photo credit: Sean Stevenson)

The general system architecture is best exposed by the following diagram:

The minimal system architecture required to make ProxiScientia work

There is still a lot of work in our research and development agenda to enrich the preliminary implementation of ProxiScientia with extra features and properties we deem essential to provide and increase developer awareness. More to come… Stay tuned!

Some career-related tips from IEEE

I recently received by mail the IEEE guide to starting your career, a brief brochure divulging several tips from this prestigious organization. I believe in free knowledge, thus this post shall comprise two sets of tips taken verbatim from the guide. The first tips are related to building your professional network and the second to finding your career path.

Build your professional network

Successful networking can be an art form—and knowing how to impress people can translate to a stronger network and a promising technology career.

1. Know your goals: Networking events can range from learning seminars and cocktail hours to volunteering activities. Ask yourself what you really want to get out of networking and pick events that align with your golas.
2. Be genuine: Networking is about building relationships—being authentic and helping others is just as important as seeing how they can help you.
3. Ask interesting questions: Prepare for events and be able to ask questions that go beyond “What do you do?” or “Are you hiring?”
4. Become a resource: Call people who you think may benefit from your knowledge, express an interest and share ideas. Potential employers remember people who stand out—so show them what you can do!
5. Follow though [sic]: Act quickly on the referrals you are given. Don’t wait too long to make contact—or you may be forgotten.

Find your career path

Being successful, at whatever you want to do, is a life-long journey. There is always room for improvement, and employers notice employees who take that extra initiative.

1. Get in there: Don’t be afraid to go for your dream company—even if you don’t get the perfect job. There’s nothing wrong with working your way up, and your perseverance will impress decision makers.
2. Be innovative: Stand out by thinking outside of the box. Stay on the lookout for creative solutions to problems that will make you, and your boss, look good.
3. Ask for more: Helping other departments, or asking for more responsibilities, increases your value within the organization.
4. Find a mentor: Mentors, inside or outside your company, are great sources of information and career guidance.
5. Build your reputation: Your reputation is the most valuable thing you own. Be known for being dependable, professional and cooperative—and people will take notice.

Hope these tips will be of some ancillary guidance to recent graduates out there. Good luck!

Humanizing the CSCW philosophy

An important step in preserving the rigorousness of CSCW as a discipline would be to humanize it per its foundational concepts. That is, we need to derive ways to illustrate its principles in practice: in real-world complex distributed systems and environments. This may sound infantile since, after all, CSCW is about practical perspectives. But that would be the case only if its theoretical foundations were no less sound than those of other established disciplines. In light of that, I should want to argue roughly about the ostensibly paradoxical employment of CSCW practices in self-organizing complex systems (alluded to mainly in Section 3 of the Bannon & Schmidt 1989 paper) and what its real implications could be on such systems.

Bannon and Schmidt’s perspective that CSCW is about positing the set of requirements that shall provide support to entities working cooperatively seems to me to be compliant with the inherent properties of complex, self-organizing systems. It is thus essential to view CSCW as a field that studies the analysis and design of interfaces and artifacts that assist such complex environments. This may sound counter-intuitive, however, since self-organizing complex systems, wherein patterns eventually emerge, do not (or should not) require a central template executed by external/central authorities. In order to avoid possible controversies, i.e. to avert mingling with the natural evolution of complex systems, CSCW systems must, in my opinion, remain minimally as mere supports congruent with the three core issues laid out by Bannon and Schmidt, but also exhibit high degrees of freedom in the selection of different information channels thanks to which interaction of entities (humans) is made possible. In other words, CSCW artifacts could be construed as establishing bounds to self-organization in distributed systems by creating new constraints (and, maybe, less complexity) in the environments. Thus, if CSCW must deal with socio-technical issues, such as aligning its (technical) processes with the (social) aspects of the environment and vice versa, it may be susceptible to violate the self-organization principle of such an environment by inducing changes which may disturb the natural emergence and adaptation of collaborative work if, and only if, the constraints it creates drastically impede the natural, adaptive system workflow and interactions in the environment. Hence, I raise the question, to what extent should CSCW systems be bounding self-organization so that the system remains resilient articulation-wise?

In turn, this elicits another weaker question: Can the discipline of CSCW ever be generic enough in terms of theoretical methodologies to provide mechanisms that study and explain cooperative work in various complex software engineering worlds? Consider, for instance, the Internet in a CSCW context: it is quite loose, but it’s the ultimate CSCW artifact for collaboration.