[roughfalls]

I once read a statement attributed to Steve Ballmer that every six months, he tears his todo list in half and throws the bottom half away. If anything far down that list was actually a priority, it will naturally get re-added (by thinking of it again, in response to a customer, etc.).

My implementation of that approach is to do the following each month:

    1. Export all my unfinished todo items older than 6 months.
    2. Place that export alongside my other backups.
    3. Then delete those items from my todo app.

I deliberately do not look at any of those items during this process, lest I be tempted to dive back into them.

That way, I limit my total mental clutter while retaining some peace of mind, since I know that I can get back to those items (I sometimes attach photos, notes, etc. to tasks) if needed. I never do.

[klenwell]

That's an interesting idea. I picked up this book, Principles of Product Development Flow, based on some recommendations I think I came across here on HN:

https://www.goodreads.com/book/show/6278270-the-principles-o...

Reinertsen really helps you appreciate the costs associated with queues (of which the TODO list would be a common form) and this seems consistent with the principles he advocates.

One key quote related to this that I am still trying to wrap my head around:

Few product developers are aware of the causal links between high capacity-utilization, queues, and poor economic performance. Instead, developers assume that their cycle times will be faster when resources are fully utilized. In reality, as we shall see later, high levels of capacity utilization are actually a primary cause of long cycle time.

[TeMPOraL]

> In reality, as we shall see later, high levels of capacity utilization are actually a primary cause of long cycle time.

So what's the reason explained by the book?

(My guess would be something along the lines of: high level of utilization lead to sudden peaks in load exceeding available capacity, and thus throwing a wrench in the process as you scramble to add capacity.)

[jwhitlark]

100% use of nearly anything is over use, not just because of peaks in load, but because it must both be done and perfect.

Think of a bookcase. 100% means you can never add more books, and it also makes it very difficult to reorganize anything.

[beams_of_light]

That explains Windows Vista.

[oftenwrong]

At a previous job we practiced aggressive, automated ticket de-prioritization. Every N days of inactivity, a ticket would drop one priority point (and I think higher priority tickets were de-prioritized at a higher rate). The theory was that anything that was truly high priority would have been done. In other words, things that we left on the queue were actually lower priority than marked. Given our extremely limited developer-hours, it was important to stay focused on the things that actually mattered.

[LrnByTeach]

That is interesting one.

Backing up - and looking at it years later gives you a perspective on your thinking process in the past years Delete - leaves lean set of Todos to focus on, without blogging down by laundry list of old things.

> I once read a statement attributed to Steve Ballmer that every six months, he tears his todo list in half and throws the bottom half away. If anything far down that list was actually a priority, it will naturally get re-added (by thinking of it again, in response to a customer, etc.).