Our hero, sitting alone in a ready room in an above-top-secret facility that the rest of the world will never know existed. A countdown timer, ticking away, menacingly. Only a handful of days left. A map showing some kind of object that appears to be approaching our solar system from interstellar space. She’s ignoring the countdown and the map and looking at something through the glass — something shadowy but dimly glowing. She is anxious.
Settling back into work after shuffling everything around can be tough. Remembering where you left everything is the first challenge, then figuring out how to actually dive back into those tasks is another. I thought I’d share my way of managing the pile of things that need to get done.
On my last project, which amounted to literally millions of lines of code, as well as some modeling, graphics, and even documentation, there were three places where I found that my “to do” list manifested itself.
One was my e-mail inbox. “Hey Pat, we need a button on this dialog that does this and this.” If I didn’t have time to do that exact task at that exact moment, then I would just close the e-mail and it would sit in my inbox until I got back to it. So my inbox would fill and empty as requests came in and eventually got done. That’s not ideal, obviously, because it has no real order to it, other than the order in which the e-mails were received. No tasks had any sort of priority or progress associated with them. However, the good thing about that system is that it’s really efficient. A request comes in, I either deal with it or leave it immediately and get back to what I was working on. It requires almost zero effort on the developer’s part, aside from maybe sending a reply like “Ok, I’ll get to that after I finish this other button I’m adding to this other dialog…”
The second method was the highly-structured bug database. We went through multiple databases and “Assembla” was probably my favorite. Every task has a “ticket” and every ticket has tons of customizable information. Everything has a priority and an owner and each thing can be broken down into sub-tasks, and tickets can be related to each other in different ways, e.g., “Ticket 500 can’t be completed until ticket 475 is done,” and so on. Every user that needs to know the status of a certain ticket can choose to receive e-mails any time something changes. So, these tickets tend to turn into little discussion forums. For a project as big as my last one, this kind of task management is almost unavoidable. My only complaint about it is that it’s too much information. You inevitably reach a point where you have a hundred “open” tickets at any given time and it can easily become overwhelming. There are some nice tools within Assembla to help manage all that information, like filters and tags and sorting, but I never really felt like I had a handle on the big picture. It was still just a giant wall of text that I had to stare at to figure out what I should be working on.
So, my third to-do list became a sort of “master” list. I would maintain a text file that contained the subset of tickets that I really cared about, and it would look something like this:
New text parser - regular expressions - add math functions - reverse parsing, save to file Crash in 2D plot window (ticket 700) - Can't reproduce crash on XP - Windows 7? - Only happens while logging is active
… and the list would just grow in a loosely structured way. Each task was roughly broken into smaller tasks and the more important things would generally move to the top, but there was no real system to it.
This third way of tracking things was the one I relied on most, and it evolved into what I currently use. Instead of a nested list, I create an actual graph. That’s what you see in the blurry image at the top of this page. A graph might seem cumbersome, but it isn’t. While doing some work completely unrelated to “to-do lists” on my last project, I discovered yEd. yEd is one of the most beautifully designed pieces of software that I have ever seen. It’s just one of those tools where everything is right where it needs to be. Drawing a chart is so intuitive that it’s really no harder than typing in a list like the one above. But the great thing about a graph is that it really does have structure and you can immediately see that structure with just a glance.
This approach really encourages the developer to work from big to small, which is tremendously important for us software guys. I start at the absolute highest level and create a box that says something like “Make a game.” Yes, seriously. From there, there are only two choices: A) complete that task and mark it done, or, B) break that task into smaller tasks. Since I can’t sit down and finish the task “Make a game” in one sitting, I create other boxes that spread out like a tree from that box. Those sub-tasks are things like “Music” and “Graphics” and “Create a blog” and every other thing I want to do to accomplish the task “Make a game.” And that process of subdividing repeats until every single box is at a small enough level that it can be done a day or two. The boxes at the smallest (leftmost) level are things like “Write an emissive map shader.” Or, often, there are things that I need to do but don’t yet have enough information to even break them down into smaller tasks. So one branch of the tree might end at a box like “Learn how to do depth-of-field blur,” for example. And when I get around to reading up on depth-of-field blur techniques, I come back to my graph and fill out that branch.
When a task is finished, I just color it green. That way, the graph becomes a really useful and visual overview of the whole project’s status. So far, I’m finding this much more productive than my old text lists.
If you’re wondering, the image above is the current to-do graph for getting Ladon to an Alpha version. I guess I should get back to work!