Planned Overtime means Planned Failure

"...you can push as much as you'd like, but you still can't think any faster." source

"9 women can't make a baby in a month."

"You can't fit 2 gallons in a thimble no matter how fast your pour." source

Software managers need to get 2 words out of their head: planned overtime.

There's just no excuse for planned overtime in a software project. And it's not just because people don't like it (though from a morale point of view, that's enough reason).

The trouble with overtime is that it begets more overtime if not managed very carefully (it's a slippery slope). The concept of "making up time" for a late item is a fallacy. You're likely to think it will work after your first work item runs late. By the time the 2nd one also runs late, something should smell funny to you, and by the 3rd time a work item runs late, you should know better! The reality is, if a couple items early in the project run late, and you work overtime to make up for them to get back on track, what makes you think that the rest of the schedule was actually estimated properly? Oops, there you are in a state of continuous overtime.

Steve Maguire uses the analogy of a sinking ship to demonstrate how the knee jerk reaction of overtime actually hurts the chances of success. If a ship is sinking at sea and the Captain orders all the sailors to bail water, this may help for a short period of time, but eventually all the sailors get too tired to bail and everyone goes down with the ship. Instead, they should be looking for the leaks...

I like to think of it as "good overtime" vs. "bad overtime". Planned overtime is bad overtime. No matter how good you believe your project plan is, it is wrong and things are going to take longer than expected. So if you're already cranking up the overtime in the plan, you've left yourself absolutely no buffer to give a little extra push if some correctable slip does occur - you're already at maximum capacity.

Working overtime is like red-lining a car engine. You can do it once and a while to get maximum performance while accelerating. But if you constantly run your engine that way, it's simply going to blow up.

People that advocate regular planned overtime demonstrate their clear lack of understanding of the software development discipline. It is a highly creative activity and one that has many serialized pieces (this can only be done after that). In many cases it's tough to parallelize the problem to get it done faster by adding people or working evenings and weekends. You're better off looking at the causes: Are we trying to do too much? It's there a simpler thing we could build that still solves the customer problem?

Whole books have been written on the subject of the effects of overtime, but basically it boils down to this:

1. Poor planning leads to the original need for overtime
2. People working overtime convert to a "do the minimum thing necessary to get this off my plate so I can go home" mentality
3. Tired developers generate more bugs
4. The quality decreases (in terms of defects)
5. The quality decreases again (in terms of the lack of creativity outputted by tired and unmotivated developers)
6. The extra bugs and poor design create larger maintenance responsibilities, which, if they don't hit you this release, they hit you in the next one
7. The wise leaders that advocated planned overtime in the first place will devise a clever solution of working yet more overtime to get back on track!

The thing that bothers me most about "planning" to deliver a project with overtime, is that right out of the gate, you've pre-determined that your application is going to be built by zombies (i.e. really tired people who don't care anymore) - and we really already have enough of that kind of software in the world. How about we plan our projects so that we can have fresh, energized, motiviated, creative people who are passionate and commited build our software instead?