This is something I wanted to get off of my chest for some time: the given fact that most GTD software applications are pretty much unusable in life scenarios. I know that’s a bold statement, but I based it on my years long experience with several of those applications. It basically comes down to the inability to handle large amounts of information. Most GTD applications (both laptop/desktop aimed and mobile apps) seems like an exercise in implementing a GTD-model in software, instead of being aimed at building a tool that actually works in real life applications.
So what’s wrong
Screens have beautiful layouts, clearly for showing the developers great taste in UI-design, instead of aiming at handling a vast amount of information in an efficient and handy way to work with. Not all available tools have this problem, but most do. And although I do like a nice UI like most of us, I want a functional UI first. The golden rule ‘form follows function’ seems almost absent in today’s software development practices, at least when it comes to public web portals and mobile apps.
The second issue is that many tools don’t even use a ‘real’ database to store all the related data, going for a one-file storage model that needs to get loaded into memory. Seriously, an XML-file is no substitute for a real database engine unless it’s handled like a database engine (i.e. pointer-based record access), and most XML-engines don’t work that way. Building an indexed array in-memory (which is easy, reason why it’s used so often) still means -all- data needs to be loaded first, so that doesn’t fix it.
The final outcome is that most GTD software applications seems more of a ‘proof of concept’, showing how such an application might work, but not able to handle more than just a few to-dos and/or projects. For any person working a day job that is at least slightly demanding and having an active personal life besides that, it’s not uncommon to have a hundred or more (small) projects going and over a thousand to-dos, which averages to just ten per project, not counting ‘stand-alone’ tasks. Try those amounts in any GTD application and you see what I mean. As long as you have ten to twenty tasks and about five or so projects, everything is fine. But that amount is obviously only what is minimally needed to demo such an application, the ‘falling down’ comes later when there is a load of time invested in using the application (as I experienced many times).
Why do developers build unusable (GTD) software
Well, this goes for almost any software project: the developers are NOT the users! This is one of the main problems in software development and will remain to be for the unforseeable future. The disconnect between the perception of a developer and the user experience, will always simply ‘be there’. But, I hear you say, developers use GTD as well, so they ARE in fact the user. That is true, but they are a special breed of users: developers are rarely also the company executive and if they are, it’s a very small company. There are probably not that many projects running concurrently and they will be fairly small projects in most cases. Besides that, software developers are NOT known for their very active social lives 😉 . So most developers that are actually using GTD (and building their own GTD software), do have a different use case then the average GTD user. So the disconnect is still there.
Some software examples
I’ve used several GTD applications over the years, with varying success and even more varying personal issues with each of them. Over the next few weeks I will post reviews of most applications I have used, and my personal experience with them. Finally, the last installment of this upcoming series of articles will be my current solution, and how I came to that.
So, if you’re interested in GTD and specifically in using a software application to support your own system, stay tuned 😉