Painless Software Schedules by Joel Spolsky

​As a rule of thumb, each task should be from 2 to 16 hours. If you have a 40 hour (one week) task on your schedule, you’re not breaking it down enough.

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.

When you first add a task to the schedule, estimate how long it’s going to take in hours and put that in both the Orig[inal] Est[imate] and Curr[ent] Est[imate] columns. As time goes on, if a task is taking longer (or shorter) than you thought, you can update the Curr Est column as much as you need. This is the best way to learn from your mistakes and teach yourself how to estimate tasks well.

Update the elapsed column every day. Updating your schedule daily should only take about two minutes.

Put debugging time into the schedule!



Author: Michal Zuber

Full stack developer, biker and rollerblader. Owner and developer at Co-founded Blog at

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s