Summary: We’re shooting ourselves in the foot with sleep debt and accumulated bugs
Action needed: avoid all-nighters, get 8 hours of sleep, fix bugs sooner

Up, periscope! The time before a trade show is of course a busy one. Let’s look at the topic of productivity. There is a great article on why “crunch mode” (working longer hours) doesn’t work. Although written from the experience and perspective of a software manager, its lessons can be applied to just about any salaried job. I recommend reading it in full; of its excellent points, we will cover two (sleep and bugs) in more detail.

• Total (!) sustained work output is highest at 40 hours / week, as found by numerous industry-conducted studies;
• Sleep matters, even one additional hour;
• Longer work times can only yield short-term gains for a few weeks;
• Implementation errors can cause NEGATIVE productivity. [1]

Fatigue

In my opinion, the root cause is that us humans get tired: “fatigue is arguably one of the most persistent threats to mission success during sustained or continuous operations” [2]. The armed forces have therefore conducted studies on the extent of the problem. Ever wondered how drone aircraft are operated? Shockingly, “40% of the study sample reported a moderate to high likelihood of falling asleep [..] while operating a weaponized, remotely piloted aircraft” [3]

In a systematic study of prolonged sleep deprivation, measured performance relating to reaction time, logical thought and vigilance drops by 20-30% within 18 hours and 50-60% within 42. [4] Similar results are observed for self-reported fatigue, negative mood and sleepiness. [4]

The only conclusion that can be drawn is that all-nighters are silly, self-defeating mistakes, yet they persist in the form of hackathons.

Let’s move on to the more common case of chronic sleep restriction, in which we get too little sleep per night over long durations. In a more recent study, groups for which sleep was restricted to 3, 5 or 7 hours/night saw increasing reaction times, the more so the less they slept. Those allowed to sleep 9 hours experienced no such decline. [5] Even after only a week of 7-hour nights plus 3 recovery nights, performance remained 10% lower than the 9 hour control group. [5] Unfortunately, only the 3 and 5 hour groups reported higher subjective sleepiness values. [5]

My takeaway is that 7 hours of sleep are not enough for most people, that there are measurable consequences, and that we may not be able to notice them.

Bugs, bugs, bugs

The second point concerns bugs – design/implementation mistakes will always be made (though more frequently when tired, per the above). How we deal with them makes a big difference.

Microsoft apparently learned this with the first version of Word for Windows, as reported by Joel Spolsky. [6] Programmers were working very long hours (see above), but throughout it all the managers stuck to an unrealistic schedule. This encouraged rushing out incomplete and shoddy code, knowing that testers would find, puzzle over and report the missing behavior. However, the problems were already known and would have to be fixed before shipping anyway, so all this did was waste everyone’s time. Worse, the schedule devolved from a reliable and accurate instrument to a “checklist of features waiting to be turned into bugs”. After major stress and a much-delayed release, Microsoft did some serious soul-searching and realized this “infinite defects methodology” is unworkable. Instead, priority would be placed on fixing known bugs before writing any new code. This has several advantages:

• fixing bugs is faster/cheaper when the logic is still fresh in mind;
• the schedule becomes much more predictable (bug-fixing time varies, and shouldn’t be carried forward as a burden on future schedule items);
• the product is always nearly ready to ship and can easily react to external circumstances.

Sounds pretty compelling. By contrast, a brief look at the horrible internal Word data structures lends support to the theory that the infinite bug methodology does not produce good results. That mistake has echoed throughout three decades. Let’s do better, by planning time into the schedule for bug-fixing and doing things right the first time.

References

[1] http://www.igda.org/why-crunch-modes-doesnt-work-six-lessons
[2] http://www.dtic.mil/cgi-bin/GetTRDoc?AD=ADA405012
[3] http://www.dtic.mil/cgi-bin/GetTRDoc?AD=ADA477976
[4] http://pubs.drdc-rddc.gc.ca/BASIS/pcandid/www/engpub/DDW?W%3DSYSNUM=47733
[5] http://onlinelibrary.wiley.com/doi/10.1046/j.1365-2869.2003.00337.x
[6] http://www.joelonsoftware.com/articles/fog0000000043.html