Nov 07 2007
Joel Spolsky’s FogBugz world tour comes to Dublin
This morning, I am bunking off work for a few hours to come and see Joel Spolsky’s talk on the Irish leg of his Fogbugz world tour. I’m looking forward to hearing a little more about the FogBugz product, although to be honest, I’m much more interested in hearing him talk about software process management and some of the other topics he covers on his blog and in his books. I considered live blogging the event, but it’s much more likely I’ll just post an update later on.
Update
So I enjoyed the FogBugz event, but not as much as I thought, and not in the way I thought I might. Here’s the story.
Joel started his demo of FogBugz 6.0 and did a great job of showing off the software. He seems like a nice guy, a good speaker with a good sense of humour. I have to admit that I didn’t know a lot about FogBugz, I last looked at it quite a few versions ago when I recall that it was not available as a service and available only on the Windows/IIS platform. It has come on leaps and bounds, and I have to say I was mightily impressed. Stand out features:
- The Wiki, for creating specifications in Fogbugz, with a very nicely done WYSIWYG editing bar.
- Evidence Based Scheduling, which enables you to calculate the probable ship date for individual developers based on past estimates. You have to see this work to see the benefits.
- The ability to take and post a screenshot with a bug report in a few clicks. Simple, but a real timesaving feature.
The best feature for me was, of course, the UI, which had some really nice features and fantastic attention to detail, for example:
- If you type
Next Monday
in a date field, it will resolve to a properly formatted calendar date. - Switching to use the shortcut keys will overlay the appropriate keystroke on all of the buttons and links.
- Context awareness, exactly the right options are available to users depending on their task. The developers of this software clearly use it themselves.
So what was not to like? Well I was a little disappointed that the questions from the floor didn’t draw out Joel’s opinions on Software development and the industry in general. We did get a few fascinating anecdotes, such as why the MS Project development team don’t think it wise to use MS Project to plan and manage the development of the product; or why there are few true dependencies in a software development project, even though project management tools encourage users to create lots of them in Gantt Charts.
I could have asked a few questions myself, I suppose, but I felt a lot of pressure in the room to stay focused on questions about what FogBugz could or could not do. Maybe I was wrong, but that’s how it felt. There was a chance to talk to Joel and his business partner Michael after the demo, but I had to run off to a meeting with a client. Anyway, it was good to see Joel speak and to see what a great job Fog Creek has done with FogBugz, even if I didn’t get as much of Joel’s insight into the business of software as I would have liked.
Technorati Tags: Dublin, FogBugz, Joel Spolsky
Johm, any chance you could expand on “why there are few true dependencies in a software development project”? It’s an interesting snippet!
Personally, I’d love to see a project management tool that focused on the actions rather than the dates - but it seems to be a paradigm that’s never been explored in any project tool I’ve come across. I know that Z follows Y follows X, but I don’t know when I’m going to start on X so why do I have to pick an arbitrary date before I can explore the structure of the project?
Hi Rob, Joel was responding to a question from the floor on how you might represent dependencies between tasks in FogBugz. His answer was that they didn’t have an explicit dependencies feature because he believes there are few real dependencies in the writing of software.
The example he gave was that you might be assigned to write some code that processes the output of some other guy’s code. People usually enter that in a gantt chart as a dependency, but it really isn’t. There’s nothing to prevent you writing a function to return some data, such as your code will expect, and then working away on your assignment.
So most of the dependencies in project plans for software development are bogus, assuming, of course, that you have a decent speciofication to work from.
I also found the dependencies snippet interesting, it makes all those Gantt charts you see in software companies look incredibly pointless.
I guess the Gantt chart represents the order in which the final product can be put together, but not soo much the order in which the code can be written.
and I think that’s the thing with FogBugz - you have to respect it as a developers tool, not so much as a project management tool.
If FogBugz allowed its cases to be broken down into tasks it would be much more useful to all concerned. A project manager could track on business level progress while developers retained the freedom they need to describe and manage the tasks that drive the result - free of any bogus dependencies.
I’m caught between management and developers and for me it’s a problem of project scope, time, and a human limit to the amount of information that can be remembered and communicated for a variety of purposes.
In our small team most developers love or at least respect FogBugz and I think it’s a great tool for recording and communicating single task issues - but how many single tasks exist free of wider concerns? For the management crew, FogBugz filter results are way to obscure and turning these into useful projects reports means tons of labour in your favourite charting tool.
This might be an unreasonable request of the FogCreek people but … there’s a level of project/development communication that they could address by adding one more reportable layer - and I’m calling it the Bogfugz Layer.
where did all that come from? jumping off the hobby horse now - J