My New Time Management Plan

For the past two months I've been involved with the two prime games at Pezad: Entrippy and unnamed platformer. Here is how I will devote my time between both now:

• I will alternate each month.

It might be too convoluted for me to attempt comprehension of this plan though, but as long as I remember that unnamed platformer will take my "hobby programming time" every January, March, May, July, September, and November, and Entrippy will take February, April, June, August, October, December, I'll be fine. I decided upon months as the time frame because months are coarse enough that I can create a deadline for at least one or two components at a time, but not so coarse, I hope, that it wouldn't feel like I was abandoning one project over another, and not so fine that I wouldn't be able to get anything useful done.

There are bound to be a few "thought overruns" where I need to finish up a few loose ends in one project but the month is over. To mitigate this, a secondary part of the plan is this:

• I will not schedule any programming tasks to initially take more than two weeks.
• Each programming task must be broken down into sub-tasks which take no longer than two days each.

The scheduling problem will still occur, no doubt, but as long as it can prevent some train wreck of a schedule overrun that spans two months or more, I'll consider it a success.

But why two weeks, you ask? Well, I think I read it in Rapid Development somewhere. It is also brought up in Game Coding Complete, probably (I read the first edition though) . The same goes for the two days thing. The idea being, if I wasn't able to break the task into such small parts, then I probably didn't have it well-defined to begin with.

However, one of the benefits of the two-day maximum rule doesn't apply in the hobby off-hours work I'm doing at Pezad. With a two-day maximum specified for each task, the programmer can easily see if he was falling behind schedule, and could work some overtime to bring it back in line. If this wouldn't be enough time, the programmer would re-adjust the schedule (probably no more than a few days) and notify the manager. The estimate would be brought back in line, communication takes place, and all interested parties stay informed.

...The beauty part of the "one-or-two day sub-tasks" plan is that if the programmer finished early for the day, he goes home early. Why start on a sub-task when he wouldn't be able to finish it in the couple of hours he had? It all balances out: a little overtime here, a little relaxation time there. At least in theory.

I can't do that here though. If I drift into overtime working on these games, I drift into interfering with my sleeping goodness, and I need sleep so I can operate at work the next day. So, that's why the "initially take two weeks" is phrased the way it is, and it can extend into later the month if need be.