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?

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.

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.