In an earlier thread, Neil wrote:
I think this is a deep problem, and one not restricted to GTD. The problem is simply this:Originally Posted by neil007
Imagine a time planning system as being like an airline check-in. Let's say there are multiple check-in queues - Cattle Class, Full Fare Economy, Business Class, First Class, Secret Class for Presidents, and so on. Each class corresponds to a "priority", for some meaning of that word.
But, crucially, there is only a single check-in desk and agent.
And the system is this - the agent serves the highest priority queue first. Only if that's empty may she call on people from the next highest. When that's empty, she again calls on the next highest. But, at any point, if someone arrives in a higher priority queue than the one for the person she's handling right now, she completes the current processing, and then jumps back to the higher priority queue.
You can see where this is going.
It is entirely possible - likely even - that some tasks will *never* get served. In fact, for sufficiently low priority tasks, they may find themselves getting further away from getting served.
And this isn't a feature of GTD or any other system. It's a feature of reality. Regardless, it can still cause the sort of psychological stress that GTD aims to solve. Granted we may have all of the things we want to do written down and kept out of our brains - but it may become obvious that we are incapable of doing all of them.
I see three solutions:
a. Handle the queues (i.e. levels of priority) in a round-robin fashion. So, the agent is able to serve a lower priority client even if a higher priority one is waiting
b. Increase a task's priority according to how long it has been in the queue. Eventually, even an inherently low priority task will become important
But the problem is those is ... well, *why*? Why on earth would I want to allow what is a lower priority task get my attention if a higher priority one is waiting? Also, this wouldn't solve the problem of tasks (any tasks) arriving at a rate faster than we can process them.
So the third solution is, I think, the only sensible one:
c. Limit the queue sizes. The total workload of my various NA lists should be kept below a maximum level. When it reaches that level, I only get to add a new NA if I ditch an existing NA.