Friday, October 26, 2007
Software developers don't really like to make schedules. Usually, they try to get away without one. "It'll be done when it's done!" they say, expecting that such a brave, funny zinger will reduce their boss to a fit of giggles, and in the ensuing joviality, the schedule will be forgotten.
Most of the schedules you do see are halfhearted attempts. They're stored on a file share somewhere and completely forgotten. When these teams ship, two years late, that weird guy with the file cabinet in his office brings the old printout to the post mortem, and everyone has a good laugh. "Hey look! We allowed two weeks for rewriting from scratch in Ruby!"
Hilarious! If you're still in business.
You want to be spending your time on things that get the most bang for the buck. And you can't figure out how much buck your bang is going to cost without knowing how long it's going to take. When you have to decide between the "animated paperclip" feature and the "more financial functions" feature, you really need to know how much time each will take.
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's how you do it.
1) Break 'er down
When I see a schedule measured in days, or even weeks, I know it's not going to work. You have to break your schedule into very small tasks that can be measured in hours. Nothing longer than 16 hours.
This forces you to actually figure out what you are going to do. Write subroutine foo. Create this dialog box. Parse the Fizzbott file. Individual development tasks are easy to estimate, because you've written subroutines, created dialogs, and parsed files before.
Read more: Joel on software
QR: 