web-developer, serious schemer
Last week I had the pleasure of attending Joel Spolsky's talk on the work he's been doing at Fog Creek software. The two projects that were presented were FogBugz and Kiln. Fogbugz is a project management tool designed with a very high emphasize of project delivery dates. Kiln is a DVCS tool that is integrated with Mercurial.
Fogbugz was my favourite part of the presentation. I've worked with a few bug tracking systems (redmine/trac) and Fogbugz included some stuff that I've never seen before and now really want to use.
The product uses statistical evidence-based scheduling to assign probabilities to task completion dates and assign a probability of the team making release deadlines. Like in all bug tracking systems, developers enter an estimate on how much time they will need to complete the task and how many hours they actually spent. Over time, FogBugz makes a some what accurate judgment of the developer/team. The system shows developers things like how accurate their estimates are on tickets and whether or not their estimates are improving. This kind of thing is an easy sell to any business person but I really think all developers and teams would benefit from this feature.
The product also includes a timeline of tasks broken down by each developer. If dependecies exist between developer tasks, the system will try to estimate a probability of one developer being blocked by another. I can definitely see this being useful when trying to schedule a code sprint because it intelligently tells you how to schedules tickets within a team. Doing it intelligently is much better then random task scheduling. It would be great if in the future you could just give it a list of tasks/dependecy and tell you exactly what order to complete the task. The only problem with my proposed feature is that as developers we sometimes "feel" like doing some specific task and might be more efficient if we are not given the order. It would be interesting to see how quickly teams get tasks done when given specific order vs no order of tickets at all.
The second part of the presentation was on Kiln and DVCS. Kiln is designed to help developers make the switch over to distributed version control and conduct code reviews. This was actually a shocking part the of presentation. I was really surprised to see how many people in the room had never even heard of using distributed version control. Half of the Kiln presentation was "This is mercurial, here's how you push/pull". Initially I thought it was a little silly but then I noticed half the room was really listening and trying to understand, so I guess it was needed.
Kiln included everything I like and would want in a CVS tracker; electrified branching, project/repository visualization and intelligent search for things like definitions/references. The code review system was also really well done, though I've seen similar projects before. One thing I would have like to see out of Kiln is the support to review local repository changes/commits. The presenter used TortoiseHg to review commits/branches before pushing. I'm not sure if using TortoiseHg was used so that the presenter could get across the point "This is on my local machine, not the central repository", but it would be great if I could use Kiln to review my local revisions. Also using Kiln would also be a cross platform solution since it was web based.
Overall great presentations and great opportunity to reflect on systems I've used in the past and how they can be made better.