Philip Greenspun On Overtime

PhilipGreenspun posted a ManagingSoftwareEngineersRant in which (among other things) he praised the value of OverTime. Allow me to quote:

He mentions two books:

In his SlashDot comments, Greenspun adds:

Food for thought. --PaulChisholm


I question Greenspun's math. I don't think I spend anyway near 25 hours a week talking about program structure with my peers. I estimate my communication cost at about 10 or 15 hours per week. This is either a cheap shot or LowHangingFruit, but perhaps Greenspun's programmers could reduce communication overhead if they weren't using that clunky and archaic scripting language that he loves so much. See also LanguagePissingMatch. He also assumes that the communication cost is fixed. I would suggest that it probably varies in proportion to the amount of work being done. -- RobertChurch


You can always get some distance faster if you are burning your renewable resources up - but where will you be later on, when you need them renewed? How much better off might those companies be if they did not drive away their best talent with excessive overtime? -- PeteHardie

How much better off might those companies be is the wrong question, as that is a purely theological question, the correct question is How much better off might management be, in the short term, and then you start realizing what he is talking about.


I think this is misrepresenting Greenspun's approach. What he seems to be advocating is:

This harnesses their obsessive development urge to your company's benefit. It also gives them access to the best toys, technology and interesting problems. Everyone wins.

I didn't get the impression of a developer sweat shop. I think there are many developers who would love to work in that environment.

I agree with both these points; see below. --PaulChisholm

I suspect the developers will still burn out and it certainly wouldn't work for anyone with a family. --TomAyerst

When I said "food for thought," I really meant it. There are two extreme positions: that overtime is never productive in the long run (the Extreme position, from what I've read KentBeck and RonJeffries to say), and that only very long hours (by people with lots of energy, what JimCoplien calls "hyperthyroid organizations") lead to very high productivity. I've seen organizations which may lend some evidence to the second position; I've also seen organizations where people working eighty hour weeks were trapped in a vicious cycle, and would have done more every week if they'd work forty hour weeks. So does OverTime work some times but not other times? Are (roughly) 40 hour weeks always optimal? --PaulChisholm

ExtremeProgramming does allow for short, 1 week, bursts of overtime.


What are the implications of software developed by organizations where nobody has a family, where the org is hostile to families?

One is that the organisation will struggle to build a reservoir of experience. But most software shops don't seem to care about this anyway. They'll have a stronger team spirit because they don't have a life? I don't think software quality and family of developers has a high correlation. I couldn't work in one but I doubt it'll catch on all over because a big percentage do go on to have families.

Maybe Silicon Valley is doomed to cyclically recreate the same architectures every 10 years as the population turns over and everything is forgotten? --TomAyerst

a big percentage do go on to have families and then they become unemployable because of SoftwareAgeism (which however hits those that don't have families too) or having learned enough that they are no longer SoftwareLabourers. Haven't you noticed that as of 2005 virtually all new software jobs are being created in countries whose main attraction is considered an allegedly endless supply of singles, overtime working, bulk headcount with entry level skills? --Blissex


Note that Greenspun is writing from the point of view of maximizing short term income for the management, not from that of delivering great software, or a long term employee happiness, or even creating sustainable shareholder value. From that point of view it is quite irrelevant what happens to the minions who get burned out and discarded, or to the customers who get hastily written stuff by those overworked minions.

Management bonuses and stock options depend usually much more on time/budget/feature goals, which are hard facts, than on opinable quantities like quality or employee satisfaction or business model sustainability.

Now, from that point of view of making a lot of money fast for management Greenspun is making a good case, in the sense that often time to delivery, budget and feature list matter, but not quality or maintainability, and a strategy of squeezing employees as hard as possible at the expense of their quality of life (and quality of software or everything else) is usually legal, and maximizes lines of code written per dollar of salary, and elapsed time (but not productivity).

Even if his 25 hours per week getting coordinated logic seems weak, because as someone else observes, time spent in coordination scales with amount of things done, and is not a fixed per-week overhead.

But salary and space and other costs don't scale, while lines of code scale up (even if less than linearly), and time to delivery scales down (much less than linearly), adding more people to the project can increase time to delivery as per BrooksLaw. So yes, his comments are about a cheap shot or LowHangingFruit, but the goal is making quick money for management, not a metaphysical or charitable one.

Also note that what he writes amounts to making crunch time permanent. This happens as a rule in the game industry (http://www.igda.org/qol/open_letter.php) where time to delivery, budget and features and short term, per title considerations trump any long term ones. EA's management have become very wealthy following Greenspun's strategy (http://www.livejournal.com/users/ea_spouse/).

Greenspun's strategy seems indeed also very common in software startups designed to be sold quickly for enormous management profit (the Ariba example he makes is telling, as well as his personal experience); what overwhelmingly matters in those is to reach a liquidity event as fast as possible raising the smallest possible amount of cash.


It almost sounds like Greenspun is looking to create a workplace full of the type of project described in Ed Yourdon in DeathMarch as MissionImpossible? or KamiKaze? - high morale, strong team cohesion, and varying odds of success. The main problems are BurnOut - and yes, you can BurnOut even if you like 80-hour weeks - and attrition, since you will lose people as their interest in the project wanes and they look for something else to do with a little breathing room for hobbies. -- PeteHardie


I don't follow why he thinks the 25 hours is a fixed overhead rather than, e.g., proportional to the hours worked. If we work 80 hours a week, won't we just spend 50 hours coordinating with other programmers etc? If not, can we find out what is special about the second 40 hours and then work the same way for the first 40?

Maybe he just means the MythicalManMonth idea, that a team of 4 has less communication overhead than a team of 12. This would mean that a small team needs less overtime to get the same productivity (in terms of man-per-elapsed-weeks) as a large team. Then to get more done (per elapsed week) with a small team they need to work longer hours. This is a plausible result that sort-of agrees with his, but arrived at a different way.

A long time ago my team leader was part time. She worked a 20 hour week and delivered a lot of stuff. If she spent 25 hours catching up each week shouldn't she have been going backwards? --TomAyerst

Not a paradox, as her entire job was getting coordinated with other programmers and comprehending the structures of the systems being extended. What Greenspun is talking about is how to get the maximum number of lines of code out of coders, for the smallest amount of cash, in the shortest amount of elapsed time. --Blissex


Hmm... Where is ArsDigita now? What about all the programmers that worked those long hours. Are they rich now? RichieBielak (October 2002)

Pointless question! Greenspun's observation has nothing to do with irrelevant issues like whether the programmers get rich. The question is whether management has become rich, and Greenspun cashed out quickly and became quite wealthy. --Blissex


Now no longer a going concern. See EveAndersson's account at http://www.eveander.com/arsdigita-history.


Jesus, what a soap opera. But it's easy to see where they destroyed themselves: they took money from the wolves. The moral might be phrased thusly: Don't go to bed with anyone you don't want to wake up next to.

This is why Greenspun's bullshit about passion and overtime and obsession over quality and craftsmanship is just that: bullshit. Look what he did. In the end, he took the money and ran.

Be wary of those who seem too eager to exploit your "passion".


Good riddance to yet another greedy *^&%#@!. (And yes, I'm sure he's on a beach in the Virgin Islands, his heart crumbling into tears at what others must think of him.)

To heck with overtime. And to heck with anyone that claims it's necessary. When the final act has played out, it's just another way to &%^$#!! people over.


Sure, the key point was: From a business point of view, long hours by programmers are a key to profitability; the key is profitability, not ethical behaviour or the happiness of the headcount.


EditText of this page (last edited April 24, 2005) or FindPage with title or text search