Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

There is this question ( which is now closed as not constructive) that asked about the average productivity per day.

My question is, is there any scientific study on the productivity of programmers? I can't help but feel that doing 8 hours of quality programming work from Monday to Friday consistently is very hard. And if yes, is there any literature that investigates this?

share|improve this question

closed as not constructive by Dynamic, Walter, Yusubov, Jim G., Bernard Oct 4 '12 at 14:39

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.If this question can be reworded to fit the rules in the help center, please edit the question.

3  
if that is off-topic than chances are this is also off-topic –  ratchet freak Oct 4 '12 at 10:07
    
It's closed as not constructive, not off-topic. Sorry for the mis-info –  Graviton Oct 4 '12 at 10:11
1  
I can see that this question is getting dangerously to being close. Why someone would like to close this? –  Graviton Oct 4 '12 at 12:37
6  
Until the drugs wear off or the coffee runs out. –  Rob Oct 4 '12 at 13:20
    
Could this be moved to workplace.stackexchange.com instead of being closed ? The question and answers so far are interesting. –  Niphra Oct 4 '12 at 14:43
add comment

3 Answers

up vote 12 down vote accepted

I don't think there would be any, for the simple reason that you can't study it objectively:

1. It varies from project to project

I had to work on projects so boring that working one hour per day was already too long. With badly written requirements, badly written existent codebase and no quality whatsoever required from me, I could try my best to concentrate, and find myself browsing Programmers.SE or doing other unrelated stuff for the last three hours.

I also had to work on projects so exciting that I spend 60 hours in a week on them (without being forced to), writing not so bad source code.

In those two cases, I was the same person. In the first case, my productivity was terrible and I was able to concentrate 0 hours per week. In the second one, my productivity was high and I was able to concentrate more than 40 hours per week.

2. It varies from company to company

As an experience, you can put two developers in different working conditions on the same project. One developer will work in her own office with a dual screen fast PC, comfortable chair, etc. The second one will have a desk in the middle of a call center, with an old PC, a 56k internet connection and a 50 MB limitation for all the personal files (and no right to use USB sticks).

Two weeks later, invert the working conditions. See the difference?

3. It varies from day to day

Imagine that on Thursday, the developer knows that he will be able to quickly solve the remaining issues, that the work to do is interesting, and everything is exciting and promising. She also learnt that she was promoted, and her husband contacted her to announce some good news related to her personal life.

On Friday, the same developer finds her old dog dead and her car won't start. She's late at work and spills her coffee on her desk, etc. How would this affect her daily performance, compared to the day before?

share|improve this answer
5  
All these issues can be addressed through proper research methodology. A more severe issue is that productivity is hard (if not impossible) to quantify. –  tdammers Oct 4 '12 at 10:57
    
Once you get past all that, about 6 hours seems to be the average "useful" coding time per day. –  Brian Knoblauch Oct 4 '12 at 12:00
    
+ 1 very true. To add my personal experience - it even varies with levels of motivation. Many years ago, I worked a few bouts of 50 hours+ (not something I would actually recommend) each in a "single sitting", remaining relatively productive throughout. It was basically down to being crazy motivated, however. I'm guessing being overworked in the long-term demoralises developers, causing much of the decrease in productivity. In the long term, 6 to 8 hours is more than enough in my opinion. –  Daniel B Oct 4 '12 at 13:07
1  
4. it varies from person to person. Developer A has Adult ADD, can't concentrate on anything more than 10 minutes at a time but during that time performs briliantly (and can switch back and forth between two-three tasks like a pendulum over a day), person B is compulsive obsessive, once she's set her teeth in something she never lets go until it is done, can work 100 hour weeks on a single task seemingly without getting tired, but her output per hour is low. –  jwenting Oct 4 '12 at 13:26
add comment

These studies were done almost 100 years ago. Many times over.

Relations between industry and labor weren't exactly cozy at the start of the 20th century. Industry initially rejected demands from labor unions for a 40 hour week. A few reluctantly complied, and they quickly found that errors and rework went down, quality went up, productivity went up, and, most important of all, profits went up. The news spread fast, and so did research. There are some productivity gains with longer work weeks so long as those longer weeks aren't too long and are isolated. Quality, productivity, and profits suffer when those extended work hours last for any significant period of time. The need for extended bouts of long work weeks became viewed by management and stockholders as a key sign of inept management.

We knowledge workers and our managers have forgotten all this. Long hours are standard in the sciences, technology, engineering, and math. The arguments that those 40 hour weeks don't apply because we are using our minds rather than our bodies are fallacious. Even in physical labor jobs, the key problems with excessive work hours are largely mental rather than physical. Long hours make us stupid and error prone.

There's a reason that extreme programming has adopted a 40 hour week as one of its key tenets. It doesn't matter whether the product is manufactured or is programmed into existence. Longer hours are counterproductive and hurt the product.

share|improve this answer
3  
May I have citation? –  Graviton Oct 4 '12 at 12:39
2  
You'll have to do your own research in a good quality library. The studies you want are in paper only; you're not going to find them on the 'net. Those studies, lots and lots of them, are 50+ years old and were published in industrial psychology, industrial engineering, and management science journals. We've just forgotten that bit of knowledge or pretend that those human factors somehow don't apply to exempt workers. –  David Hammen Oct 4 '12 at 13:29
    
I gave this a +1 but it would be a fantastic answer if it had citations. –  psr Oct 4 '12 at 17:06
1  
They're asking for a citation, which is not the same as a link. When you say "these studies", do you have any specific information - names of journals, article titles, etc? Any kind of starting point, other than "a good library"? –  Cyclops Oct 4 '12 at 17:52
add comment

It depends on the project.

If i have something big and just challenging enough that I can get my teeth into I can work for a good few hours without even realising and work 12+ hours in a day. However if I don't really know what I'm doing, have no pressure or don't see any value in the work then I get distracted every half hour.

I'm sure there are books around which describe how to improve productivity (though you have to make sure you find one written by a developer not a buzz word book written by a 'management consultant') however I don't think there's any concrete metrics out there.

share|improve this answer
add comment

Not the answer you're looking for? Browse other questions tagged or ask your own question.