I’m sure everyone’s already read Joel Spolsky’s excellent discussion of Evidenced Based Scheduling, but if you haven’t you’re missing out. It doesn’t take a rocket scientist to know that scheduling is the hardest part of software. We all got into this business because we like to play with compilers and debuggers, not because we totally love creating Gant charts. Joel’s first step to successfully using Evidenced Based Scheduling is Break ‘er Down, which means that you have to break down the schedule into nothing longer than 16-hour increments for each developer. If you haven’t done that, you don’t have any hope of shipping anything. For many years, I’ve been preaching the same mantra. While it’s easy to tell everyone to have every developer and tester scheduled to that level, Joel glossed over how you go about doing the breakdown. Fortunately, after making many mistakes as a project manager and developer, I’ve found a very solid way of determining exactly how to break down all the tasks assigned to a developer.
When breaking down any task assigned to a developer, you have to answer six questions, I call the Six Its.
How long will it take to…
- Learn it?
- Design it?
- Code it?
- Test it?
- Tune it?
- Document it?
While you’re probably thinking the Six Its are obvious, sadly that’s not the case. When evaluating estimates from developers, you have to specifically look to see if they are meeting each one. If you miss one, you’ll miss your ship date.
I want to draw special attention to the first It, Learn it, as this is the one that everyone forgets to account for in the schedule. Developers are some of the most positive thinking people in the world and they never want to admit what they don’t know. Consequently, they are assigned a task and immediately start designing while learning at the same time. That means they design on a fine foundation of quicksand and end up tweaking, debugging, and fixing all through the project. Many of the performance and scalability problems we work on at Wintellect are because of bad design from developers who didn’t know what they were doing.
When scheduling the learning time, you have to break that time into the same hour increments as you would anything else. You’ll want lay out how you’ll go about learning what you need in order to avoid push back from managers. If it’s a technology that you don’t know you’ll want to show prototypes and goals in the schedule so you can prove to others you know enough about the technology to build a successful design.
While scheduling a project will probably never become fun, I hope the Six Its will make it a little more scientific instead of just wild guesses.