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
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?
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!
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"
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.
posted 15 years ago
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.
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.