• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Do fixed hour work weeks *always* make sense?

 
Author
Posts: 6055
8
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I recently became familiar with the following case. A large corporation had engaged a mid sized consulting firm well known for agile methodologies. The large corporation was eager to engage in an agile methodology.

The consulting firm had a firm believe in 40 hour work weeks (and no doubt used that as a selling point when hiring). Towards the end of the project (a website launch), it appeared that the project would not be completed on time (despite the understanding between the large corporation and the consulting firm). The corporation pushed for longer hours and the consulting firm resisted, the relationship took some damage.

Should the consulting firm stand it's ground? Should the corporation insist on longer hours at the end to complete the project?

I was thinking here the fixed hour work week doesn't make sense. Now understand that I don't think squeezing every hour out of someone is ideal, you do get diminishing returns. However, the limit is certainly not 40 hours and longer hours for 2-3 weeks at the end of a project has been shown to work.

I am actually a fan of the concept of the fixed worked week (I don't take it literally, but like the idea of not asking people to work longer ours during certain periods). The advantage, as I see it, is as follows. Many people (engineers and business people) are terrible at estimating. This is well proven. Nevertheless, when estimates are off, engineers pay the price of longer hours. By fixing the level of effort, it "punishes" all parties involved in the estimation to do better, because their goal was not reached.

However, I don't think it holds in this situation. The premise of the circumstances describe din the previous paragraph is that it's a multi-round game, i.e. many projects over many years. A consulting engagement is a one time affair so the "punishment" has no effect. Moreover, as the corporation benefits from the project success, and suffers no ill effects from burning out the development team, it seems to me that the corporation is "right" to push for it.

What do others think?

--Mark
 
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Mark Herschberg:
The consulting firm had a firm believe in 40 hour work weeks (and no doubt used that as a selling point when hiring). Towards the end of the project (a website launch), it appeared that the project would not be completed on time (despite the understanding between the large corporation and the consulting firm). The corporation pushed for longer hours and the consulting firm resisted, the relationship took some damage.

Should the consulting firm stand it's ground? Should the corporation insist on longer hours at the end to complete the project?



Seems to me that the relationship took damage because of a value conflict. I think that neither thoroughgoingness nor compliance will resolve such a conflict.


I was thinking here the fixed hour work week doesn't make sense. Now understand that I don't think squeezing every hour out of someone is ideal, you do get diminishing returns. However, the limit is certainly not 40 hours and longer hours for 2-3 weeks at the end of a project has been shown to work.



I agree that the limit of 40 hours is arbitrary. It's already arbitrary because I can work differently in the same amount of time: I can try to squeeze the last out of eight hours a day - I won't even be able to do *that* for three weeks in a row - or I can work rather relaxed.

And even that's already a too simplistic view: when working in a relaxed way, I often can get more value done - because I have more time to reflect on what I need to do next to generate maximum value.


I am actually a fan of the concept of the fixed worked week (I don't take it literally, but like the idea of not asking people to work longer ours during certain periods). The advantage, as I see it, is as follows. Many people (engineers and business people) are terrible at estimating. This is well proven. Nevertheless, when estimates are off, engineers pay the price of longer hours. By fixing the level of effort, it "punishes" all parties involved in the estimation to do better, because their goal was not reached.



To me, there is more to it: estimates are called "estimates" because of a reason: they *cannot* be accurate.

Well, perhaps in many situations they could be *more* accurate. But don't forget that getting more accurate estimates also comes with costs.


However, I don't think it holds in this situation. The premise of the circumstances describe din the previous paragraph is that it's a multi-round game, i.e. many projects over many years. A consulting engagement is a one time affair so the "punishment" has no effect. Moreover, as the corporation benefits from the project success, and suffers no ill effects from burning out the development team, it seems to me that the corporation is "right" to push for it.



I don't see that a consulting engagement is a one time affair. As far as I can tell, reputation, word of mouth advertising and follow up projects are very valuable assets for a consulting firm.

And it might be economically logical for the corporation to push for the overtime. In a healthy corporation there is more to be considered than short hand economics, though, in my opinion.
 
author & internet detective
Posts: 41860
908
Eclipse IDE VI Editor Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
> Should the consulting firm stand it's ground?
For the consulting firm, this is a multi-round game. Some of the consultants will be on other projects for the consulting firm and know the consulting company broke its word on work week. I think the consulting firm should talk to its consultants. In particular, address the situation explaining we know it is supposed to be a 40 hour work week and would like to make it longer for 2-3 weeks. Then ask the consultants if they would be willing to work more hours in exchange for more money. (Most of the consultants I know, but not all, would say yes to this arrangement.)

> Should the corporation insist on longer hours at the end to
> complete the project?
Depends on what was in the contract. Also depends on whether the overrun was entirely the consulting company's fault or if anything "unexpected" happened.

> longer hours for 2-3 weeks at the end of a project has been shown to work.
I think this should be a last resort. First thing should be reducing the amount of "other work." If someone is going to ask me to work a signficiant amount of overtime on something, it better be the number one priority. This may not apply here as consultants do sometimes work on only one project at once.

> I can try to squeeze the last out of eight hours a day - I
> won't even be able to do *that* for three weeks in a row - or I can work
> rather relaxed.
I agree with Ilja on this. I can work longer/too intensely for a short period. But I will make mistakes because I will be tired and rushed. In development, these mistakes become bugs which increase the schedule because they need fixing. Taking this to the next level, I can declare a feature done right now. I'm there is anything missing (like the feature), I can call it a bug. Of course this is unprofessional and I would never do it. It's more of an extreme example of what happens when quality isn't considered. You can't JUST negotiate time without exploring the other parts of the project management pyramid.


> Nevertheless, when estimates are off, engineers pay the price
> of longer hours. By fixing the level of effort, it "punishes"
> all parties involved in the estimation to do better,
> because their goal was not reached.
I have a coworker who calls this "not requiring heroics." I like that term as it makes things more repeatable.

> I don't see that a consulting engagement is a one time affair.
I don't either. My team works as a consulting team to another organization. We are a mix of employees and consultants ourselves to my organization which results in a bunch of points of view. We've been in this arrangement for 5 years over a series of projects. Long term commitments to matter here. And killing yourself to get one project done on time has implications for the next project. If you have a lot of hacks/rushed work, eventually the tower will crumble and a deadline is impossible. While this means we need to explain to the other organization why a "simple" feature may take 2 weeks while a more complex one takes 1 week, we build a relationship of trust. We also establish that we aren't a dumping ground for risks/problems. The PROJECT owns these, not just the development team.
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Jeanne Boyarsky:

> Should the corporation insist on longer hours at the end to
> complete the project?
Depends on what was in the contract. Also depends on whether the overrun was entirely the consulting company's fault or if anything "unexpected" happened.



Also depends on whether we think that demanding more working hours will actually deliver more value. I seriously doubt that; and I *do* know some other things that have worked quite well for our team in the recent past.
 
Mark Herschberg
Author
Posts: 6055
8
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Ilja Preuss:

Also depends on whether we think that demanding more working hours will actually deliver more value. I seriously doubt that; and I *do* know some other things that have worked quite well for our team in the recent past.



I think companies that think that simply going from a 60 to 80 hours some particular week will increase productivity that week by 1/3 are naive. It may be true in a few cases but I wouldn't count on it.

Likewise, I think people who *outright* dismiss going from a 40 to 45 hours some particular week as inherently not productive are being equally extreme. I would argue in most cases a few extra hours for a week or two generally do increase productivity. There may be other ways, even better ways, but this way will work.


--Mark
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Mark Herschberg:
Likewise, I think people who *outright* dismiss going from a 40 to 45 hours some particular week as inherently not productive are being equally extreme. I would argue in most cases a few extra hours for a week or two generally do increase productivity. There may be other ways, even better ways, but this way will work.



I can tell you that for me, personally, what I can do is working longer hours at the end of a day, or work an additional day at the weekend, to get something done that can't wait. I also need additional recreation time afterwards, though.

I'm totally sure that when developing software, working additional hours for a week or longer doesn't make me more productive. The reason is simple: it's not the amount of code I write that makes me productive, but the amount of code that I don't have to write, and the amount of code I write and I don't have to debug.

On the other hand, I don't have a problem being called extreme, anyway...
 
Sheriff
Posts: 7001
6
Eclipse IDE Python C++ Debian Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
For me the issue is right at the start of the initial question: A large corporation had engaged a mid sized consulting firm well known for agile methodologies. The large corporation was eager to engage in an agile methodology.

One of the key aspects of agile development is that it is a learning process. As development proceeds, more is learned about the needs of the problem domain. If it is discovered that more (of whatever) is needed than originally envisaged, then one of quality, time, or scope must be sacrificed to compensate.

It sounds as if the corporation (implicitly) seem to prefer to sacrifice quality, whereas the consultancy would prefer to keep consistent quality but sacrifice features. I wonder if the discussion was ever phrased in these terms?

Given that the project in question is a website, and these are by nature iterative and driven by user feedback once deployed, then deferring some scope from the first release to the second seems quite a sensible choice.

If the corporation is expecting to specify "everything in the first release and no further changes" for a web site project then they likely have much bigger problems than failing to understand the benefits of working sensible hours.
 
Jeanne Boyarsky
author & internet detective
Posts: 41860
908
Eclipse IDE VI Editor Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Ilja Preuss:
I can tell you that for me, personally, what I can do is working longer hours at the end of a day, or work an additional day at the weekend, to get something done that can't wait. ... I'm totally sure that when developing software, working additional hours for a week or longer doesn't make me more productive.


Same here. I think that part of the reason behind this is that some developers (like anyone reading this forum) are more conscious of the process. We are already working at the most efficient pace possible. Sure it is possible to "overclock" for a day or two. After that, you hit the limit and become tired. Which causes you to no longer be working at optimal efficiency.

For me, I could probably add a bit of time to my day and be equally productive. I've done this in the past by taking some or all of the time I would have spent at JavaRanch/reading tech newsletters/books and applying it towards work. While these appears to work in the short term, you then hit a point where you start working less efficiently because you are less familiar with the best approaches to do something. So this works as a short term solution to a short term problem IF I'm lucky. If I'm not lucky, I spend longer debugging stuff because I "didn't have time" to find the solution to problems or let my subconscious work on problems.

"some particular week" - This is they key phrase. Discussing extra time for one particular week is more likely to work. The problem is that many employers put a whole bunch of those "particular weeks" together for months.
 
Mark Herschberg
Author
Posts: 6055
8
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Jeanne Boyarsky:

"some particular week" - This is they key phrase. Discussing extra time for one particular week is more likely to work. The problem is that many employers put a whole bunch of those "particular weeks" together for months.



And there's the rub. Maybe I'm unusual, I can do an extra week, even an extra 2-3 without getting burned out. Longer than that my productivity goes down.

You seem to agree that you can do a day or two. Many agile developers religiously claim that any time over 40 hours a week reduces overall productivity. It seems dubious to me because I've never seen any study showing that 40 is optimal (although there are plenty of historical reasons that we have a 40 hour work week). More generally, if you concede that it can be done for a day or two, then it's not a question of whether or not overtime can in short does increase productivity, but rather where to draw the line. (I think it's because of this reason that so many developer take the religious extreme.)

--Mark
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Frank Carver:
For me the issue is right at the start of the initial question: A large corporation had engaged a mid sized consulting firm well known for agile methodologies. The large corporation was eager to engage in an agile methodology.

One of the key aspects of agile development is that it is a learning process. As development proceeds, more is learned about the needs of the problem domain. If it is discovered that more (of whatever) is needed than originally envisaged, then one of quality, time, or scope must be sacrificed to compensate.

It sounds as if the corporation (implicitly) seem to prefer to sacrifice quality, whereas the consultancy would prefer to keep consistent quality but sacrifice features. I wonder if the discussion was ever phrased in these terms?



Very good point. Especially if you imply that the consulting firm was hired to "teach" the corporation the Agile approach.

It's totally normal to fall back into old habits when problems arise, but it won't teach you something. In that context, it could make total sense to me for the consulting firm to stand firm to Agile principles. The skill then of course is to do it in a way that the stakeholders in the corporation actually learn something different than "these Agilists are fanatic extremists"... That's not always easy...
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic