Painless Software Schedules

Some excerpts from the Article on Joel On Software

So, you have to make a schedule. This is something almost no programmer wants to do. In my experience, the vast majority just try to get away with not making a schedule at all. Of the few that make a schedule, most are only doing it because their boss made them do it, halfheartedly, and nobody actually believes the schedule except for upper management, which simultaneously believes that "no software project is ever on time" and in the existence of UFOs.

So why doesn't anybody make a schedule? Two key reasons. One, it's a real pain. Two, nobody believes that it's worth anything. Why go to all the trouble working on a schedule if it's not going to be right? There is a perception that schedules are consistently wrong, and only get worse as time goes on, so why suffer for naught?

Programmers are not interchangeable. It takes seven times longer for John to fix Rita's bug than for Rita to fix Rita's bug.

When you have to pick fine grained tasks, you are forcing yourself to actually figure out what steps you are going to have to take.

And when you haven't thought about what you're going to do, you just can't know how long it will take.

If you have to figure out what subroutines you're going to write, you are forced to pin down the feature. By being forced to plan ahead at this level, you eliminate a lot of the instability in a software project.

Most programmers have no idea how to guess how long things will take. That's okay. As long as you are continuously learning and continuously updating the schedule as you learn, the schedule will work.

Updating your schedule daily should only take about two minutes. That's why this is the Painless Schedule Method -- it's quick and easy.

A programmer should never, ever work on new code if they could instead be fixing bugs.

The schedule is not the place to play psychological games.

You might be able to get 20% more raw code out of people by begging everybody to work super hard, no matter how tired they get. Boom, debugging time doubles.

But you can never get 3n from n, ever, and if you think you can, please email me the stock ticker of your company so I can short it.

Not many of them are running business what-if scenarios... these are programmers, here