[A picture of private offices at Fog Creek Software] Alert! This ancient trifle retrieved from the Joel on Software archive is well-past its expiration date. Proceed with care.

Joel on Software

2002/11/19

by Joel Spolsky
Tuesday, November 19, 2002

Good Books

The GoalA few months ago I read The Goal, by Eliyahu M. Goldratt, mainly because it has become extremely popular at business schools, and it looked fun. It was interesting, and fun. I didn't understand how the book's theory, called the Theory of Constraints, could possibly be applied to software development, but it was still interesting enough, and I figured if I ever found myself running a factory again, it would be helpful.

Critical ChainLast week I discovered his newer book, Critical Chain. This book applies the Theory of Constraints, introduced in The Goal, to project management, and it seems to really make sense.

Lets say you're creating Painless Software Schedules. Most people's intuition is to come up with conservative, padded estimates for each task, but they still find that their schedules always slip. Goldratt shows that the slip is precisely because we pad the estimates for each step, which leads to three problems:

  1. "Student Syndrome" - no matter how long you give students to work on something, they will start the night before. Phil Greenspun noticed this: "The first term that we taught 6.916, we gave the students one week to do Problem Set 1. It was pretty tough and some of them worked all night the last two nights. Having watched them still at their terminals when we left the lab at 4:00 am, we wanted to be kinder and gentler the next semester. So we gave them two weeks to do the same homework assignment. The first week went by. The students were working on other classes, playing sports on the lawn, going out with friends. They didn't start working on the problem set until a few days before it was due and ended up in the lab all night just as before."
  2. Multitasking, which, as I discuss, makes the lead time for each step dramatically longer, and
  3. the fact that delays accumulate, while advances do not (for example, if you have finished this week's work on Friday morning, chances are you will waste time on Friday afternoon rather than starting the next week's work. But if you don't make it on time, you'll still leave at 5 o'clock on Friday, accumulating a delay.)

Goldratt's solution is to choose task estimates that are not padded: each individual task's estimate should be exactly in the middle of the probability curve, so there is a 50% chance you will finish early and a 50% chance you will be late. You should move all the padding to the end of the project (or milestone) where it won't do any harm.

I can't do justice to an entire book in this short post, but if you're doing any kind of project scheduling or management, I highly recommend that you read both books (read The Goal first no matter what you do, both because it's more entertaining, and because it teaches you the foundation you need for Critical Chain).


Have you been wondering about Distributed Version Control? It has been a huge productivity boon for us, so I wrote Hg Init, a Mercurial tutorial—check it out!

Want to know more?

You’re reading Joel on Software, stuffed with years and years of completely raving mad articles about software development, managing software teams, designing user interfaces, running successful software companies, and rubber duckies.



About the author.

I’m Joel Spolsky, co-founder of Fog Creek Software, a New York company that proves that you can treat programmers well and still be highly profitable. Programmers get private offices, free lunch, and work 40 hours a week. Customers only pay for software if they’re delighted. We make Trello, insanely simple project management, FogBugz, an enlightened bug tracker designed to help great teams develop brilliant software, and Kiln, which simplifies source control. I’m also the co-founder and CEO of Stack Exchange. More about me.

© 2000-2014 Joel Spolsky