How is Software Development Different?
Although to our knowledge no in-depth research has been done to discover the relationship between productivity and hours worked in software development, substantial anecdotal evidence suggests that the results found in other fields are also valid in this one. In a recent Slashdot discussion entitled "Can People Really Program 80+ Hours a Week," the general consensus among most posters seems to be that programming productivity does in fact become negative after a certain number of hours worked. One poster, jarich, says the following about working continual 60 to 80 hour weeks:
I can't do it. The people I know who think they can do it can't do it either. We always ended up making bad mistakes that took a lot of time to clean up. We missed obvious architectural improvements that could have saved us days of work. We overwrote code and trashed data!
Another poster, calibanDNS, writes:
The lead programmer on my current project works at least 60 hours every week (and has for years) and more than that about half of the time. He's in at 6:30am and usually leaves around 6:30 or 7:00pm and he NEVER takes lunch breaks. Towards the end of the week, any problem that he "solves" quickly usually requires at least a day or more to re-fix later on.
A large number of other postings to this discussion support similar conclusions.
We believe that there is no reason to think that studies linking extended overtime to decreased total output should not also apply to software development. In fact, it may even be the case that software development is more susceptible to the detrimental effects of overwork than many other fields. There are a number of attributes specific to software development (and related fields) that have led us to hold this view.
First of all, the main activity of software development — programming — often, if not usually, requires intense concentration and mental exertion. Programming is not something that can be started at the drop of a hat or done while engaging in casual conversation: programmers often take up to an hour to "warm up" at the start of each day, and they often desire solitude for extended periods of time to engage in their work. Thus, programming is very much vulnerable to the toll that sleep deprivation and stress take on workers.
Mistakes in programming can also take a very long time to fix; much longer, in fact, than they usually take to make. While software developers don't have to worry about losing fingers or falling off of ten-story buildings when they make mistakes, they do have to worry about making the future work of themselves and their co-workers extremely difficult. Code that is written during extreme fatigue and stress is by all accounts almost always of much lower quality than code written in more relaxed conditions. Such code is often lacking in documentation, nearly unreadable (even by its creator), and full of errors. Errors — or bugs — in code are often not discovered until much later in a project when this code happens to be tested in new ways. Such errors often involve complex interactions of a large number of individually complex components and can take days, if not weeks, to find and fix. The fact that code written in during crunch mode is usually much more bug-ridden than code that is not is exacerbated by the fact that such code is usually put through much less rigorous testing procedures — usually due to lack of motivation and time.
Programming is very much a collaborative effort, and errors made by one individual will very often cascade into the work of everyone else involved with a project. Thus, it is common for one software developer to spend a great deal of his or her time dealing with bugs produced by other developers. The overwork of a single employee can thus negatively impact the productivity of the entire team. When every programmer is working long, exhausting hours this problem compounds exponentially: everyone begins to spend more and more of their time fixing errors rather than getting new work accomplished.
Finally, it is very common for software to be reused for years, if not decades, and such software invariably requires updates and other modifications. While code written in crunch mode may be completed in time — that is, to meet an often ill-conceived deadline — it is, as we have argued, generally of much lower quality than code written under more relaxed conditions. When it comes time to make updates and modifications, such code is very often much more brittle and difficult to understand, which means that such changes will often take much longer to implement. It is much more productive to do the job right the first time, rather than to do a lackluster job and then pay for it later.
As one final note, we do not mean to suggest that crunch mode and extended hours can never be productive in software development. On the contrary, we believe — and the experience of many software developers shows — that extended hours for short periods of time can and often do lead to productivity increases. In fact, this has been shown to hold in a number of other industries. It is when crunch mode is extended out over a longer period — many argue even over as little as 3 weeks or more — that it begins to exhibit the problems that we have described in this section.