To complete my previous post about GTD, I want to mention the fatal flaw in this methodology.
Getting Things Done tells you to determine the next action you need to do for all of the stuff/projects you need to do. That is good! Once you do that that action, you can go onto the next.
I’ve, in effect been doing that for Behold. Behold’s Future Plans list is the ToDo list of subitems I need to do to get Behold to become that “perfect” genealogy program. Once I pick the next item from the list, I determine the first programming “Action” to do to get that thing done. Another action follows that action and so on until that item is complete. Then I go onto the next item.
Do you see the problem here? It is the problem that has caused Behold to take so many years to get to this point. Each item has many actions, often many more than you (or I) would expect. Doing them one at a time and only worrying about the next one is a great way to stay sane and is one of the best things GTD teaches you. It helps you continually make progress.
But the problem is that GTD does not necessarily get you any closer to your final product. You keep adding new ideas to the ToDo, often faster than the items can get done. The product gets better and better but the end keeps getting farther away. Something is missing from Getting Things Done to focus you. Some method to prioritize and schedule what you do.
How to fix Getting Things Done
I don’t think it’s very hard to fix. Simply add Joel Spolsky’s Painless Software Schedules methodology into GTD. Joel wrote this in 2000, and now says the article is obsolete, but don’t believe him. PSS is very simple and integrates with the actions of GTD too perfectly to ignore. You need add only 5 columns to your Actions to implement it: an original estimate, a current time estimate, the time elapsed, the time remaining, and a priority column.
You only need a list with 4 to 6 simple columns to implement GTD, and only 5 more if you want to go the extra step and prioritize and schedule the things you want to do.
Remember, any system has to be simple and fun to use or you won’t use it.
Genealogy software needs a simple but useful ToDo list. I’ve now got the model to implement one, if and when I get there.
In the meantime, I’m continuing my push towards Behold’s beta.
Joined: Mon, 15 Dec 2008
5 blog comments, 0 forum posts
Posted: Mon, 9 Mar 2009
Interesting blog post, but at the same time I’m having issues fully believing these methodologies. Software development is like a very long road. There are always enhancements that can make the drive more scenic or enjoyable, but after a while I would like to see my destination before I run out of gas, but at the same time, you want to make sure your software has something to offer before setting it out on the world. Unfortunately, its figuring out the balance between what is needed to make the software worth while and trying to get it out that ends up being the difficult part.
I like your To Do list identifying the 3 types of items (wants, needs and bug fixes) since you at least identify the type of work. No software is ever “done” and eventually some of these items will need to be pushed in the “maintenance” phase or post release so that you can get your product out there! (or at least remove the script that has your deadline always 1 month away!)
Consider this a motivational boost to get the Beta version out!
Joined: Sun, 9 Mar 2003
288 blog comments, 245 forum posts
Posted: Mon, 9 Mar 2009
The secret, then, is probably to always have a working version that is available.
If nothing else, Behold has been available to the world for what is now 4 years. I have been told that it’s really not an “alpha” and should always have been called a “beta” because it has been released - even though I’ve given it very little marketing other than word of mouse. By releasing it early, I’ve got great feedback and input and extra motivation to help push Behold along.
This has led to incremental changes of what I consider most important at the time, which essentially has been my methodology. My experience has shown that just “doing the next action item, the next thing on your list” works for the multitude of small things you want to do, but not for big ever-expanding projects.
There is no visible end of this infinite road. And it keeps changing directions while you walk on it. What I need to do is get to a few important milestones: what I call beta, then Version 1, and then Version 2 with editing. I hoped I would have been there long ago, but I still find myself walking. The journey so far has been very enjoyable, and the milestones up ahead look even better. Stay tuned.
Joined: Tue, 14 Oct 2008
20 blog comments, 0 forum posts
Posted: Wed, 11 Mar 2009
The secret is not really a secret, Louis… . Do a feature freeze, get version 1.0 out, and keep all the good ideas you have (and you have a lot!) for later releases.
Joined: Sun, 9 Mar 2003
288 blog comments, 245 forum posts
Posted: Wed, 11 Mar 2009
You’re right Uwe. Behold’s feature set is currently good enough for a Version 1.0. What was lacking was it’s slowness, which I’m now remedying.
The current version expires at the beginning of April, and I’m working hard to ensure that the replacement will be the beta, whether or not I’ve got all of it functioning again. The beta phase can fix all that and get Behold to 1.0.
Joined: Tue, 14 Oct 2008
20 blog comments, 0 forum posts
Posted: Fri, 13 Mar 2009
Depends on what you consider “slow”. If you test Behold’s speed against giant gedcom files with 100000+ individuals then this is a somewhat extreme case. How many genealogist out there really have such a big database? I guess it’s less than 1% of your potential customers.
Not that I want to prevent you from optimizing Behold, though… ;-)
Keep up the good work!
Uwe
Joined: Wed, 8 Apr 2009
1 blog comment, 0 forum posts
Posted: Wed, 8 Apr 2009
GTD does not replace planning or prioritization. But it will help you get stuff out of your way you have to deal with anyway. Hence so many custom implementations exist. You have look at the desired outcome first - your project goal - the defined feature set for the next release. Then define a cut off (or feature freeze).