Julio Santos

I’ve been reading Joel Spolsky’s “Joel on Software” blog for several years now and though his good stuff is becoming more and more rare, you can still find really good gems on his site.

More specifically I would like to revive his Painless Software Schedules article, which it’s still at least as relevant today as it was five years ago.

Here Joel recommends a very light (and useful) way for developers to schedule their stuff. I’m not going to paste his entire article here. Just enough to give you a taste, and hopefully raise awareness that, in fact, estimates don’t have to be hard, and more importantly they can actually be useful.

Here is the skinny:

1. Keep it Simple — it’s the old “less is more”
2. Each feature should consist of several tasks — Break it down to simple, manageable tasks
3. Only the programmer who is going to write the code can schedule it — You’re the one doing it, don’t let anyone else tell you how long it’s to take you to do it.
4. Pick very fine grained tasks — keep each task at the *hour* level, not week or even worse
5. Keep track of the original and current estimate — Keep track of your estimates (Ideal Engineering Time) vs. what actually happened (Real Engineering Time)
6. Update the elapsed column every day — Spend only a few minutes a day doing this, nothing more
7. Put in line items for Vacations, Holidays, etc. — Make sure you take those, if you don’t do it for you, do you for your team!!
8. Never, ever let managers tell programmers to reduce an estimate. Again, if someone thinks they can do it better, let them do it
9. A schedule is like wood blocks. — Work on the critical stuff first, so when the schedule starts to slip, management has options: add more people if it makes sense, cut features (the non critical features are done last, so it’s all good), delay the release, or even cancel the project if that’s what makes sense.

The keyword here is “options”. The more accurately and frequently you update your schedule, the more options management will have. If they discover in the last week that the 6-month project is not going to make it, then they are left with much less options. Perhaps just miss the deadline or delay it.

The next recommendations I don’t entirely agree with, but for completeness, here they are:

1. Use Microsoft Excel — I actually agree that there’s no need to use heavy duty specialized software such as MS Project, but I’d also argue that MSP has its place and can be a good tool if you use it properly. Either way is fine, it’s just a tool, can be misused.
2. Put debugging time into the schedule! — It should be part of the task itself instead
3. Put integration time into the schedule. — Integrate often and your life will be better
4. Put buffer into the schedule. — Work on the most critical stuff first, update your estimates often, at least once a week, and there will be no need for buffers.

There are other techniques, namely Extreme Programming which go beyond Joel’s recommendations, and I’ll save those for some other time.

If you are sloppy, and pick big “chunky” tasks (”implement grammar correction”), then you haven’t really thought about what you are going to do. And when you haven’t thought about what you’re going to do, you just can’t know how long it will take. — Joel Spolsky