Wednesday, May 14, 2008

Improve My Software Delivery Commitments

In Oct 07 I first read about the Evidence Based Scheduling feature of FogBugz. I like reading Joel Spolsky because he seems to tell it straight regardless of the subject. This time, it stung. Software projects are chronically late. Most projects I have been on in the last 9 years are no exception. When I read this article, I took up courage to ask a co-worker about it. He was excited about using something like this.

Well we took the plunge. We tried FogBugz for a month in January and then bought some licenses. I recently got a new supervisor. She seems willing to try out FogBugz as our software project management tool.

From Evidence Based Scheduling,
Why won’t developers make schedules? Two reasons. One: it’s a pain in the butt. Two: nobody believes the schedule is realistic. Why go to all the trouble of working on a schedule if it’s not going to be right?

Over the last year or so at Fog Creek we’ve been developing a system that’s so easy even our grouchiest developers are willing to go along with it. And as far as we can tell, it produces extremely reliable schedules. It’s called Evidence-Based Scheduling, or EBS. You gather evidence, mostly from historical timesheet data, that you feed back into your schedules. What you get is not just one ship date: you get a confidence distribution curve, showing the probability that you will ship on any given date. It looks like this:

The steeper the curve, the more confident you are that the ship date is real.
Here is a 70 minute video Joel Spolsky made in Oct 07 that explains the Evidence Based Scheduling feature of Fogbugz.

Frederick P. Brooks in 1987,
Not only are there no silver bullets now in view, the very nature of software makes it unlikely that there will be any—no inventions that will do for software productivity, reliability, and simplicity what electronics, transistors, and large-scale integration did for computer hardware.... I believe the hard part of building software to be the specification, design, and testing of this conceptual construct, not the labor of representing it and testing the fidelity of the representation.... If this is true, building software will always be hard. There is inherently no silver bullet.
Fogbugz is not the golden goose that will solve all software development problems. As I persist in my discipline to use it, it will help me make more accurate delivery estimates.

No comments: