Trac has become an indispensable tool in my geek/work life. I’m running several instances for several projects and just can’t imagine working without it anymore (just as I can’t imagine to not work with some sort of version control anymore).

The main reason probably why I’m so happy with trac is that it’s fairly configurable and non-invasive as far as any sort of management- or ticketing software is concerned. Meaning that some of the aforementioned projects are quite different in their nature from each other, yet I was able to adapt trac surprisingly well and (occasionally) surprisingly easily (trac being written in python helps, I guess).

The use case I want to talk about today is that of planning and managing a software project. As I’ve previously blogged, I nowadays tend to divide projects into (at least) two cycles of planning/discussion (billed by the hour) and execution (fixed price, fixed delivery date). Going through these cycles pretty much guarantees that the specification is both finetuned and realistic (because every cycle of specification except the first is based on working prototypes) but of course it doesn’t alleviate one from creating, committing to and being true to a delivery date!

Entering into the third iteration of specification/implementation in a current project we were a bit overwhelmed at first on how to deal with scheduling and managing it. The basic approach was a given: we’d follow Joel Spolsky’s authoritative article on Painless Software Schedules which dictates to break down all tasks into subtasks until each remaining task is estimated at no more than a couple of hours for implementation. Joel warns the reader to go overboard when keeping track of those tasks and suggests a simple excel table.

Well, I simply applied the principle (sub-eight-hour tasks tracked with a simple tool) and applied it to trac. So, having a fairly exhaustive and well-matured set of specifications and screenshots sanctioned by the client we then sat together and created a) for each screenshot one ticket in trac and b) read the specification out loud to each other (don’t laugh - we were surprised how important that step turned out to be!) and creating additional tickets as we went along.

The ‘trick’ was though, that I had added two custom fields to trac: estimated time and actual time (which is easily done by just adding a few trivial lines to trac.ini). As we created each ticket we collectively agreed on an estimated time. After having entered all tickets we were then in the happy position (using a custom sql-based query) to arrive at a precise total of estimated man hours — and based on that, of course, an estimate of cost and finish date.

Meanwhile the project is already well on its way and the simple effect of being able to measure our progress against ‘the plan[tm]’ at any given time is invaluable. Fact is, I’m actually a bit behind with my current milestone (ArchgenXML/Poseidon can be full of surprises, yay!) but instead of just getting that sinking feeling of failure I now can simply schedule an additional day for the project this week (i.e. tomorrow) so that by the beginning of next week I should be back on track (pun intended).

And, of course, one can’t stress enough how incredibly useful trac’s seemless integration of wiki and subversion is - I guess, you just need to use it for a while in order to appreciate it…

And in next week’s episode: writing a trac plugin for managing clients and creating invoices based on tickets — use trac to earn money and lose weight!