An insidious force in software development continues to make reasoned trade offs between projects difficult, if not impossible. Whether you call it free time, casual overtime, unpaid overtime, or "blood from a turnip," organizations that do not measure this gift from their development teams cannot make accurate decisions when faced with "Do we do Project One or Project Two?" because they cannot estimate the true cost of either project.
The term free time was the inspiration for this article as it is perhaps the worst name for overtime I have run across in my career. Paid or not, overtime has many negative consequences on personal as well as business levels. I will discuss both, but will emphasize the negative business consequences in the hope that those who focus on the bottom line to the exclusion of all else will see that ignoring free time does not make good business sense.
The Personal Side
My first job out of college was working on the Apollo Program at Kennedy Space Center. The goal to land on the moon by the end of the decade was a challenging goal that created strong motivation to work long hours. Sixty to eighty hour workweeks for extended periods (years) was not unusual. Although most of the overtime was paid, Brevard County, Florida, had the highest divorce rate in the country in the late 1960s. One has to wonder if the steady seven day work-weeks had anything to do with this.
In a later job, I regularly visited a team working on a critical project, typically after lunch. As they fell behind schedule, management decreed they would work overtime to catch up. For the first three to four weeks, I observed a concentrated effort on the part of the team. As time went on, I noted their lunch breaks became longer, and their focus was poor in the afternoon hours, with extended discussions of non-business topics. Overall efficiency was down and in spite of the extra hours; did they really accomplish that much more?
On another occasion, an ex-boss and friend lamented that his project management had decreed the team work Saturdays "until the project was back on track." I asked my friend how far behind schedule they were. Thirteen weeks was the answer.
I asked, "When do you have to deliver?"
His answer, "Six months."
Some simple arithmetic which he had already done and every person on the project was capable of doing, figures 13*5 = 65 days, or more than a year, to make up the schedule deficit, assuming further slips did not occur. The logic of this decree to work Saturdays in situations like this erodes what respect and confidence the team has in those who make the decrees.
Add to this the increased rate of mistakes made by tired people, the loss of creativity, the added stress on physical well being, and the forced tradeoffs in personal and family activities. This would seem to be enough to mitigate the use of overtime--whether paid or not. Sadly, this isn't the case. I know of one company where project managers were measured in part by how many hours of free time they squeezed out of their people. Since people issues seem to be ignored, let's look at business reasons why free time isn't free.
The Business Case against Free Time
Let's take two projects in the proposal stage and show what happens if free time is not accurately estimated. Note accurate estimation typically requires recorded data from previous projects, or--worst case--an organization's memory of a past project history that allows the next project to estimate