Last time, I talked about the refrain " ... about two weeks." This time, I'd like to talk about another Myth: The idea that we can "make it up later."

        Let me explain.

        Let's say that you are asked to estimate how long it will take you to drive home - something you do twice a day, every day, and have done hundreds of times. You might say, perhaps "an hour" based on past history.

        That afternoon, it snows. Twenty minutes into your drive, you pass an accident that takes the road down to one lane. You don't get half-way through the drive until fourty minutes have passed. Your wife calls to ask what time you will be home, as she has dinner coming out the oven at the exact time you promised.

        What would you say? "Sure, I'll be on time, I'll just make it up later"? I don't think so. No, you are more likely to be intellectually honest - not just admitting that you are now ten minutes behind, but assuming that the traffic conditions will lead to more accidents ... and you might be home later.

        Let's take this a bit further: Suppose that when she first asked you, your wife wanted to know the exact time you'd be home. What answer would you give? More likely, something like "An hour, plus or minus twenty minutes." Or suppose she wanted a time you would be home by, guarenteed? Most likely, you'd say "Two Hours."

        Applied to software development, this gives us some very interesting problems. In his book Rapid Development, Steve McConnell points out that planning to make it up later is a classic mistake - you never make it up later. For starters, forced overtime is a game of diminishing returns. Eventually, forced overtime causes enough burnout to be counter-productive.(*) In addition, if you are late, it probably means the project is simply harder or more comples than you though. For example, if you are 25% late when you finish the specification, McConnell points out that you should probably add an additional 25% delay to the schedule for all of the other phases, because. fact is, you're probably going to run 25% late.

        Software Managers have spent years trying to figure out ways to deal with this. Extreme Programming and Staged Delivery offer the possibilities of cutting features and shipping something on time. Joel Spolsky, author of JoelOnSoftware.Com recommends having the biggest feature on your list be called "buffer" and robbing time from that feature when running late. Watts Humphries, of the Software Engineering Institute, suggests tracking the ration between your estimates and actual deliverables and creating a "load" multiplier. The authors of Successful Software Development suggest measuring the projects risk and increasing your estimates to account for that risk. The author of Software Engineering: A Practioners Guide suggests negotiating to cut features, add resources, or ship late when faced with a project that is running late.

        Any way you slice it, they all suggest actually dealing with the problem instead of merely hoping that it will go away. The reality is simple: You ain't gonna make it up later.

---

(*) Note: Different companies have different cultures. In some companies, "Code-Like-Hell" overtime is compensated by very relaxed undertime between projects. If the coders, and friends and family, can deal with this, this could be a healty work environment. Even Kent Beck, father of Extreme Programming, states that an occasional week of mild overtime is simply part of being a professional. The dicussion above is not about being a professional, it's about overtime abuse.