Win a copy of Testing JavaScript Applications this week in the HTML Pages with CSS and JavaScript forum!
  • 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 all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Bear Bibeault
  • Ron McLeod
  • Jeanne Boyarsky
  • Paul Clapham
Sheriffs:
  • Tim Cooke
  • Liutauras Vilda
  • Junilu Lacar
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • fred rosenberger
  • salvin francis
Bartenders:
  • Piet Souris
  • Frits Walraven
  • Carey Brown

To Authors: Working hours

 
Ranch Hand
Posts: 137
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
What is your take on working hours? Do you think 12-16 hour days will benefit the project? Or will 8 hour days be more productive as the project participants will be well-rested and more motivated?
 
Ranch Hand
Posts: 94
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I think it depends on the status of the project..
If it's still "in control", 8 hours a day is the best.
But if it's on a critical status.. 12 hours a day is still reasonable. But from my developer's point of view i suggest no more than that.
remember that we have to sleep 8 hours a day to be healthy
 
author
Posts: 113
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Originally posted by Morten Andersen-Gott:
What is your take on working hours? Do you think 12-16 hour days will benefit the project? Or will 8 hour days be more productive as the project participants will be well-rested and more motivated?



First let me point to a blog entry by Andy Hunt:
40+ Hour Work Week Known to be Hazardous

The key words in this post are "sustainable pace". You don't want to turn out one product, you want to turn out a lifetime's worth.

I think it's okay to put in some long hours to get a project back on track (if you inherit one), and I've done that. But if you are still working more than 8 hours a day after two or three months, it indicates a lack of planning. We've used the The List as a planning tool to combat this.

Another concept I'll point out is the Death March. This is when the company wants you to work 80 hours weeks for months because ~this~ project will save the company. It is becoming universally accepted that a Death March project will always be thrown away! The company that can't plan their software efforts can't plan sales or marketing either.

So working 18 hours days is not only no healthy, it's a waste of your time!
 
Ranch Hand
Posts: 54
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
From the TOC, I believe there are quite a no. of topics being discussed that will also help to 'control' the working hours of the developers (as least prevent it from increasing). For example, "features keep creeping in"
 
Ranch Hand
Posts: 192
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Yes, I agree that its lack of planning that developers are asked to work for 12+ hours a day. But how should we handle if things go out of our hand. For e.g., if our manager comes and say work for few more hours daily, and asks to come on weekend too, how to handle it? If project management is not done proper, it ends in everybody suffering.
 
Jared Richardson
author
Posts: 113
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Originally posted by Arun Prasath:
Yes, I agree that its lack of planning that developers are asked to work for 12+ hours a day. But how should we handle if things go out of our hand. For e.g., if our manager comes and say work for few more hours daily, and asks to come on weekend too, how to handle it? If project management is not done proper, it ends in everybody suffering.



I would suggest you get involved with the planning. Use The List (from Ship It!) to document what you are doing and what you teammates are doing. Then show The List of features (with time lines, priority, etc) to the boss. There is a danger of the boss trying to wring more work out of you when he sees the time for each feature, but I've never had that happen (and I've worked for a few bad ones).

At one shop I was asked to work on three issues. They were really big in terms of work and importance, but I thought I could get them done in a week. Two days later my boss dropped in and asked me to get an additional item done too. I simply told him that I couldn't do that... after his jaw had bounced off the floor, he got a little upset and wanted to know why I couldn't do what he was asking me to do. I pulled out my copy of The List ( a legal pad at this point) and showed him the time requirements for each of three items already on my plate.

He saw that something had to give. I wasn't rebelling against his orders, I was pointing on the inevitabilty of the calendar. He adjusted the priority of one of the orginal features. This left me three issues to address within the time line (1 week).

I had stumbled into a key concept. Share information with a decision maker and they'll make better decisions. Don't share information and they'll get upset and frustrated.

Your boss isn't an idiot. Sometimes he seems like one, but he's really a regular person just like you. If he understands what you are trying to get done, you might have a better chance of getting a workable schedule.

Another tack: have the short (1 to 2 minutes per person) Daily Meetings. Everyone tells what they've done, problems they've had, and what they plan to do today. Now, invite the boss to the meetings. It will let the boss see that everyone is actually working hard and making progress. You pull back the curtain on the world of development and let them see the inner workings. They'll come away with a better appreciation of what you do and how you do it.

If it all fails, and you are stuck in a Death March, then read Death March: The Complete Software Developer's Guide to Surving Mission Impossible Projects .

A Death March is a forced march. In software, it's the long mandatory overtime for months on end. It's rarely effective (due to the mistakes sleepy developers make) and is (even worse) an indication that the product you are building will never see the light of day.

A company that can't manage a software project is (more than likely) also not managing their sales, market research or advertising projects either. So even if you decide to stay for the crazy drive, just be aware that the researchers assure us that the project will never sale a copy.
 
Tony William
Ranch Hand
Posts: 54
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
If I am to summarized what, as the team lead, should do to make managers to become more 'reasonable', it would be:
  • make things clear (totally agree that we should keep our manager updated with what we are doing
  • ask for prioritization
  • even better, to make up a detail-enough work plan and ask for manager's review / comments


  • [ August 02, 2005: Message edited by: Tony William ]
     
    Don't get me started about those stupid light bulbs.
      Bookmark Topic Watch Topic
    • New Topic