Last time I said I’d talk a bit about my preferred tools for software project management. Right now, I’m a huge believer in just using the bug database. Pick a good one, a web-based one, and I can’t see any better tools out there today.
It has to be on the web
Firstly, I believe firmly in using a web-based system. Think about some of their key characteristics:
- Collaboration. Web-based software inherently means simultaneous concurrent access; no longer does your schedule need to be checked into source control and locked by one person at a time.
- Distributed. I believe in letting the most detailed level of scheduling being done by the people closest to the work; overly-centralised scheduling will not do for me.
- Integration. Think about all the other tools you use: IM, email, wiki, … web-based software integrates smoothly, all through the beauty of the hyperlink.
- Accessibility. Very few developers will want to install, let alone use, dedicated desktop software for project management. But they’ll have a browser open all day long; opening an extra tab is nothing, the web UI is familiar, and hyperlinks draw them into the system effortlessly. A web-based system is the only way you’re going to involve and engage your developers in the schedule.
Of course, merely being on the web is not enough. You wouldn’t manage your project on Facebook!
Mixing bugs and tasks
The first games I worked on were split into 2 phases: pure feature development followed by pure bug fixing, with dedicated tools (MS Project followed by a bug database) for each phase. I think a lot of games must have been made this way. It’s always bothered me:
- It’s not good from an engineering standpoint; even though rule 5 of the Joel Test is not to be taken literally, the spirit is right: deferring bug fixing to the end is inefficient, demoralising, risky, and detrimental to eventual quality.
- It’s not good from a management standpoint, because even projects following this model inevitably do bug fixing throughout – and if they’re managed with Project, this isn’t reflected in the tools being used. These projects are either in denial about the reality of what’s going on, or they’re duck-taping the two systems together, say by having a fixed percentage allocation of time to bug fixing in Project. Either way, the tool is not supporting what’s actually happening in the project.
What is a bug anyway? There are plenty of clear-cut cases, but also a big grey area between bug, improvement, usability enhancement, and new feature. Why try to classify them? Who cares? To me, what matters most is that I have a list of things to do, I have an idea of how long they’ll take, I have an idea of how important they are to the product, and I work in the most sensible order based on that information – in other words, I prioritise. If a new feature is higher priority than fixing a bug, I should do that next. If the bug is more important, I should do that next.
I think categorising work as bug or feature is only useful to the extent that it helps you quickly sort and slice the data when prioritising a lot of stuff. Once you mix bug work with new feature work, and stop caring too much about neatly classifying work as one or the other, you really need a tool that provides a unified schedule, allowing you to prioritise all your work in one list.
If this sounds a lot like Agile, that’s because it is. Despite my issues, this is something I totally agree with: managing projects ultimately boils down to managing lists of stuff to do. Bug trackers have emerged as fantastic tools for managing lists of bugs; it turns out they’re just fantastic for managing lists of work, and it doesn’t much matter whether that work is bugs or not.
Bug databases have known all of this for a while. Jira doesn’t just use the “bug” word: it’s also an “issue tracker … from software bugs and help-desk tickets to project tasks and change requests”. Fogbugz “makes it simple to track your projects”, with Scrum support and innovative scheduling tools. Bugzilla describes itself as “server software designed to help you manage software development”. And so on.
Bug databases have a bit of a bad image for some – it’s not long since they were smelly VB/MFC thin wrappers around a crappy database crammed with boring fields, a horrible UI, and forever associated in developers’ minds with an unpleasant end-of-project crunch. But they were born to be on the web, and have really excelled as a market segment since web applications took off. Look at the world’s best bug databases today and you see incredibly high-quality, good-value, powerful, pleasant-to-use software.
Does it work?
Personally, I’ve done this on a complete project once – on our in-house tools team over about 4 years with 5-10 developers. Right now, I’m helping to put it into practice on a much bigger scale on APB with its 100+ developers – so I’ll have many more data points, and plenty of interesting experience to talk about, by some time next year 🙂