It is evening, and the windows are beginning to tarnish as the daylight retreats over an unseen horizon. People are finishing up for the day, getting into their cars and onto trains, going home to their families. Yet in an office somewhere, indubitably, the work continues as evening melts into night. Computers emit silky white noise, keyboards chatter in staccato bursts, the music leaking from headphone sets sounds like the click and whine of insects. And somewhere in that office, someone will be rubbing their eyes and thinking to themselves that they really should be going home and seeing their kids, even as they turn back to their computer screens.
If this scene sounds familiar then that’s not particularly surprising given that the TUC estimates UK workers put in over 27Bn GBP of unpaid overtime in 2009, which works out to an average of around seven extra hours of work a week. Those workers undertaking “computer related activities” are particularly hard hit by this trend, with nearly 40% of IT workers regularly working more than their contracted hours.
To some extent, dedication to a job beyond the terms of the contract seems inevitable. In a society which largely defines individuals in terms of what they do, pride in ones work is essential for a person’s self esteem. Furthermore, the team structures of most modern workplaces could almost have been designed to exploit the kind of self-interested altruism which evolutionary psychology would argue is hard-wired in humans. This combination of pride and loyalty to the group make it natural to want to go the extra mile when the circumstances seem to require it.
For IT workers, these more general factors could be seen to be augmented by further motivations to go above and beyond the call of duty. As a profession, IT demands a certain fascination with knotty, absorbing problems; and a certain dogged determination in solving them. In addition, and perhaps in common with other knowledge workers, IT professionals seem as motivated by the job itself as they are by the financial rewards of the job.
Insofar as people work overtime because they love their jobs, are loyal to their teams, and are motivated by the challenges of their work, it is possible to view unpaid overtime as a part and parcel of being a professional. But that doesn’t make it harmless. Indeed, the cautionary tale of ea_spouse‘s experiences of her husband’s time working for Electronic Arts strongly suggests otherwise:
“The main thing I want to know [of Electronic Arts] is: you do realize what you’re doing to your people, right? And you do realize that they ARE people, with physical limits, emotional lives, and families, right? Voices and talents and senses of humor and all that? That when you keep our husbands and wives and children in the office for ninety hours a week, sending them home exhausted and numb and frustrated with their lives, it’s not just them you’re hurting, but everyone around them, everyone who loves them? When you make your profit calculations and your cost analyses, you know that a great measure of that cost is being paid in raw human dignity, right?”
Whilst ea_spouse’s ordeal is an extreme case, it is nevertheless symptomatic of an industry which views unpaid overtime not as just the inevitable consequence of dedicated professionalism, but as a bankable resource which can be factored into the bottom line just as easily as a round of redundancies or a rewrite of the pension scheme rules.
This kind of sweat-shop employment practise is clearly immoral. Depressingly, the long hours of EA’s development teams may actually be completely unnecessary, as Computer Science researchers have found some evidence that long-term overtime is ineffective, if not detrimental to project timelines. As Joel Spolsky notes of ea_spouse’s essay in The Best Software Writing I:
“There is a major school of thought in software development, of which I am a member, which says that programmers who work more than 40 hours a week for extended periods of time actually get less work done than programmers who are not in crunch mode all the time… Even if all you cared about was the employer’s perspective, if all you cared about was what Electronic Arts should do to maximise their profits, the permanent crunch time policy is still completely counterproductive”
Indeed, this would seem to be borne out by many examples of software projects which decline to rely on overtime to get the job done and yet still achieve resounding success. For example, the engineers working on the Space Shuttle software explicitly avoided a long-hours culture, as FastCompany noted back in 1996:
“It’s strictly an 8-to-5 kind of place — there are late nights, but they’re the exception. The programmers are intense, but low-key. Many of them have put in years of work either for IBM (which owned the shuttle group until 1994), or directly on the shuttle software. They’re adults, with spouses and kids and lives beyond their remarkable software program.”
In other words, no mega-crunch efforts, no vast swathes of unpaid overtime, and no heroic coding efforts. Just good, well managed software engineering which resulted in software with defect rates of around a third of one percent of that of a typical commercial project of the same size.
So why doesn’t everyone do it like that? Although the Space Shuttle software team’s work was of the highest standard, it was also extremely expensive compared to commercial software development. Furthermore, it was carried out within the rarefied environment of the aerospace industry where requirements are so tightly specified and controlled that developers never have to worry about the client changing his mind, or the marketing department adding features at the last minute. As such, the methodologies used by the Space Shuttle team simply don’t work for most commercial projects.
It is here, perhaps, that we find the root of the IT industry’s tendency toward reliance on heroic programming. Invidious companies aside, software engineers end up working long hours due to the failure of development and management methodologies to deal with the realities of the market they are working in. This may be due, to a degree, by the lack of a clear best practise approach to software development in a complex and shifting market; but it is equally true to say that many software managers make little effort to improve their methods. The result is management that is mediocre at best, and whose default response to slippage in the schedule is an exploitative development crunch.
So, software engineers, next time you’re still hacking away at work long after your children have gone to bed, just consider what it is you’re doing there. Are you so absorbed in your work and your passion for the job that it never occurred to you to go home? Or are you simply carrying the can for your company’s deficiencies?