Timetough: fast time tracking for FogBugz
Timetough: Screenshot | Download (needs pytz)
Paul Graham has a little essay called Startups in 13 Sentences. Numbers 7 and 10 are my favorites:
7. You make what you measure.
10. Avoid distractions.
Avoiding distractions is another way to say staying productive. If an entrepreneur's greatest asset is their own time, and one makes what one measures, then measuring your time should make you more productive with your time, right?
Well, that's the theory I'm testing. So I'm back to using FogBugz. It has nifty integrated time tracking and schedule estimation features. However, I find that a web interface is simply not fast enough for efficient time tracking. The clicking, the reading, the loading. Derailed. For fast time tracking, here is a text file format format I've come up with:
03/17/2009
09:33 101 12:00
12:00 42 13:30
The sparsity of the format really cuts down on mental friction. Here are some specific notes:
- Using the 24 hour clock is faster than using AM/PM.
- I had to spend some time making sure my virtual machine's clock was syncing properly, and had the correct timezone configured.
- I came up with some Vim macros to insert the date- and timestamps, so that part is really fast.
- Putting the case number between the start and end times mirrors the order that I think of them in. Fetching the case number occupies the first 0.1 to 10 seconds of working on the new case. The FogBugz "Working on" widget doesn't start the clock until I've located the case number. It also gives me lots of additional clutter. Clutter == friction.
- Dealing exclusively with case numbers means that my brain ends up hashing them. So for very frequently used tasks, fetching the case number is instantaneous.
- Currently active tasks are open in a browser tab in a FogBugz-dedicated window. So in the second instance, fetching the case number takes a second or two.
- Third-tier tasks take 10 seconds or so to go searching for in FogBugz.
- The field order also makes switching tasks really fast: Ctrl-T, Enter, Ctrl-T. This is crucial for reacting to phone calls, emails, and kids barging in the door. :^)
- I regularly need to tweak the timestamps, for example, when I forget to switch cases until five minutes into the new one. This is a big value of a text file over FogBugz's "Working on" feature. Slamming out a timestamp and then tweaking it is a very cheap operation in my system. The parallel in FogBugz is using the "Timesheet" feature. Click, click. Read, read. Load, load. Derailed.
- In FogBugz, you can't record that you're working on a case without giving an estimate for the case. But estimating is really a task unto itself. You want to batch that work rather than trying to squeeze it in between other tasks.
So that's my format. Now I need to get the information back into FogBugz, so I can use their Evidence-Based Scheduling and other nifty abstractions. I wrote a program called timetough for this purpose. It uses the FogBugz API to post entries from my text file timesheet back into FogBugz. It protects against conflicting work intervals (i.e., an already-posted timesheet), and it prompts you for confirmation when you are trying to post time to closed cases. It also starts off by prompting you to add or update estimates for all of the tasks on your timesheet: batched estimation, the way it should be.
After having worked more closely with FogBugz' time tracking, I do have some questions about its design. First, it's not designed for standing tasks, such as I'd like to have for administration chores. This shows up especially in that you can't bill time against cases that don't have estimates. Standing tasks by definition have no expectation of completion, so for the moment I am using 0.01 hours as a special-case estimate along with a completion priority of 7 (the lowest) to indicate a standing task.
Second, FogBugz is optimized for shipping software. It is not as well-suited to time-and-materials work: I can't find a report that simply tells me how much time I've spent on a project Update:Found it; see comment below. The FogBugz API means that one should be able to make something work for these scenarios, but this is the sort of understanding it might be helpful to have up front when considering the system. These are also suggestions for future FogBugz development.
Thirdly, FogBugz imposes a stronger concept of "shipping" software than I'm used to for web apps. My experience to date has been that web software evolves more than it ships. However, while certainly not approaching the rigidity of "shipping" old desktop software, I think FogBugz' focus on delivering a product is probably good. It fits with the focus on productivity that I'm after here, especially as it involves teams of developers and not just a lone ranger.
So with that all said, here are a couple screenshots to whet your whistle. Here is a basic run of timetough:
And here is what the same info looks like once inside FogBugz:
Hrm ... looks like I under-estimated on Case 85. ;^)
P.S. The name is from this song:
