Every so often you will come across a comparison of drunk driving to trying the same action while sleep deprived. This usually is surprising to spectators when the lack of sleep is shown to be as bad as consuming a lot of alcohol. Although developers tend to be comfortable drinking and drinking alcohol, they are far more known for long hours and lack of sleep. Maybe this correlation can also be extended to the larger than average project failure rates.
The Caffeine Culture
I have met very few developers over the years that are not proud of their caffeine consumption. It is a badge of honor to walk into a late night session with six packs of energy drinks. This becomes their standard approach to the long hours regularly required of those that chose to code as a career. The problem is that the long hours are inflicted as much as they are elected. I have experienced a countless number of projects where the approach to hitting target dates is to cancel time off and extend hours to seventy or more per week.
The typical attitude is to grab some energy drinks and pour more hours into a project to get it on track. I have no problem with this approach. However, I do question those that are surprised by lower quality after these pushes. You can design and test all you want. However, a team that is comprised primarily of sleep-deprived members is roughly the equivalent of those same people after an evening of adult beverages.
Mental Work
When you consider how much more mental coding is (as compared to driving) the problems become apparent. You have people that are not at their best mentally doing tasks that require concentration and complex thinking. Once I started down this road, it seemed evident that these projects would have high amounts of errors and thus failure rates. The worst part of all this is that those increased errors cause more time to be needed to get tasks done. That leads to less rest and sleep, which leads to more errors. Thus, a death march is born.
The amusing thing is that many companies have policies that go as far as terminating those that show up for work inebriated. Yet, they have no problem demanding the long hours that can lead to the same mental state.
A Different Path
There are some instances where the long hours come from poor planning or management. Unfortunately, many of the situations arise from heavy competition, low budgets, and the related tight deadlines. You may argue that means that team leaders are left with no choice. I would say otherwise.
When you look at productivity curves for the average human, you see a drop off as the day gets “too long.” Studies show the length of a comfortable (and productive) workday varies from worker to worker. Nevertheless, we can work with averages and observation.
I recommend that adding hours and pushing for longer work weeks be done in an incremental way. Ease your way into it earlier in a project if it looks like it will be needed. You can then closely observe the developers and bug rates to see how things deteriorate. At some point, there will be a diminishing return that makes long hours not only useless but detrimental. Once you have that hard limit, you are better served to add resources or accepting slipped dates.
Developers may like to be “edgy” by embracing sleep loss and long hours. However, this is not a productive approach to software. Maybe treating them as imperfect humans will help improve project failure rates.
