Do Long Work Hours Affect Code Quality? 911
tooTired asks: "At my company the owner is heavily implying that the development staff needs to start working longer hours and weekends to shorten the time-frames on our current projects. The exact quote is 'These 8 hour days have to stop, we need to be working 15 hours a day and weekends, balls to the wall.' We are heavily under-staffed even with my multiple attempts to show the owner that we need more resources. My general feeling is that long hours is generally a symptom of poor project management, and not something to be sought after. I wanted to ask the Slashdot community their opinions on how working long hours during the week and weekends affects the quality of the code they produce, and the overall success of the project." A large reason why many in this industry find themselves working long hours and weekends is that management makes unreasonable expectations and deadlines. Are there ways of communicating to management that long hours to rush a project to completion is not the way to complete a successful project? Update: 08/30 23:11 GMT by C :Grammatical errors in title, corrected. Sorry about that.
Agreed (Score:5, Interesting)
Nevermind code quality - what about burnout, resentment towards management, and seeing domain knowledge go out the door when coders get sick of working 15 hour days and leave for another company?
15 hours? He's not serious, is he?
Hmm... (Score:3, Interesting)
I am not owned by a company. (Score:3, Interesting)
These 8 hour days have to stop, we need to be working 15 hours a day and weekends, balls to the wall.
The company doesn't own me. Period. If I heard that statement from my boss, I'd be in my car and on my way home before she had a chance to even blink at me. Despite I do frequent Slashdot, I have a life outside work. When I get hired by X company, I didn't sign on so I could spend my every waking hour and moment working for that company. Any manager who doesn't realize an employee has a life outside the company isn't qualified to manage employees. Period.
Re:Agreed (Score:5, Interesting)
Why? Because the European Union protected its workers by introducing the working time directive which emans the maximum hours you can be contracted to work is 48 per week - you can work longer if you wish and agree, but no employer can force you too, and if you decide not to there's not a thing they can do. Even if later they decided not to promote you on that basis you could take action against them.
Usually I'd be cautious about such intervention, but certainly here I have to agree that it's to everyone's disadvantage being forced to work these crazy hours - I've done it myself and veryone loses - employer, employee and families.
Long hours... (Score:3, Interesting)
Sometimes, there are days/weeks where it is neccessary for the team to put in some unreasonably long hours in order to get the project done. Especially during the time immediately before a release/launch.
That said, when I ask my staff to put in long hours, I'm there with them. If the team doesn't need "management", I roll up my sleeves and do whatever needs to be done whether that is coding, infrastructure work, or being an HTML monkey.
I don't think it is reasonable to ask for that sort of performance on an ongoing basis or for an extended period of time. It is very draining.
I also think it is very important for both myself and the organization to show it's appreciation for the people who make these sort of sacrifices for the company. This includes:
When people are running late, pay for the pizza. Look for other ways to be considerate.
Have some sort of launch festivities. Celebrate your success. Publicly acknowledge (preferably -- not just within IT) the people who made it happen.
I think that if management and the company treats its employees reasonably well, that the techies should be willing to work their assess off and burn the candle at both ends when needed.
Re:Yup (Score:3, Interesting)
Also - driving your employees like sled dogs will cause them to look for employment elsewhere, and if you don't think that will effect your code quality, you shouldn't be leading a pack of cub scouts, much less a project with a real product.
The biggest problem with management is that they make decisions they aren't qualified to make. I see it time and time again- it only takes one PHB shooting his mouth off to get the whole development team 6 months behind before the project even starts.
Sorry- managers are like alcoholics- you can't tell them they have a problem because they think you're out to get them. This is particularly bad in technical jobs because managers that were promoted from within have poor social skills which are necessary to be a successful manager.
Re:Spend The Time Wisely (Score:5, Interesting)
Of the dotcoms, practically none, but then none of the dotcoms that didn't work that waysurvived either. Conversely, look at the older Silicon Valley companies that did make it. How many of those were born from huge efforts by their staff? Apple. Cisco. Palm. Intel. HP. Sun. The list goes on; all companies that were and/or still are legendary for the long hours they expected of their employees.
This doesn't prove that long hours are a good thing, but there are at least counter-examples to the claim that this approach never works out.
Re:Yup (Score:3, Interesting)
Um...do you live on a planet where programmers are paid overtime?
Time for Physical Exercise (Score:3, Interesting)
Oh, btw, hope you don't smoke, or all bets are off.
Re: Agreed (Score:5, Interesting)
> Humans are not machines. You simply do not up the hours that they are 'on', and it works.
I was never interested enough in this to read up on it, but supposedly there were studies several decades ago that showed that the total output for a week's work peaks at some certain number of hours and rolls off after that - even for jobs like construction work. I don't remember the exact number (and it probably varies by trade), but it was certainly less than the 15 hours/day that his idiot ^w boss ^w idiot boss is wanting.
From personal experience, I'd say that for a steady-state arrangement my gross productivity (i.e., total per week rather than total per hour) peaks at around 50 hours a week. I can be productive throughout a 12 or maybe even 14 hour day if I do it occasionally, but for a steady-state arrangement I think I actually accomplish less working 12-hour days than I do working 8-hour days. I would guess that working 15 hours/day would be about as productive as working 3 hours a day.
With apologies to Brooks, I conjecture that suddenly doubling the working hours would hurt productivity as bad as suddenly doubling the staff, if not more.
Also, I notice that the asker describes his boss as "owner", and my experience with Pa & Ma shops is that the owner/boss is often running the business more as an exercise in ego than in economics, so he might want to ask himself whether the suggestion isn't more a raw demonstration of power than an attempt at economic efficiency.
All this is speculative, of course. But anyone interested in this stuff might want to look for some published reports on hours vs. gross productivity, and also reflect a bit on the underlying motives for management decisions when manager=owner.
2 opinions: Steve McConnell and Philip Greenspun (Score:5, Interesting)
"Chapter 43: Voluntary Overtime: Too much overtime and schedule pressure can damage a development schedule, but a little overtime can increase the amount of work accomplished each week and improve motivation. An extra four to eight hours a week increases output by 10 to 20 percent or more. A light-handed request to work a little overtime emphasizes that a project is important. Developers, like other people, want to feel important, and they work harder when they do."
"Use a developer-pull approach rather than a leader-push approach.... Gerald Weinberg points out that one of the best known results of motivation research is that increasing the driving force first increases performance to a maximum, and then drives it to zero (Weinberg 1971). He says that the rapid fall-off in performance is especially observable in complex tasks like software development: 'Pressing the programmer for rapid elimination of a bug may turn out to be the worst possible strategy-but it is by far the most common.'"
"Don't use overtime to try to bring a project under control.... Ask for an amount of overtime that you can actually get.... Beware of too much overtime, regardless of the reason."
Slashdot discussion of [Philip] "Greenspun on Managing Software Engineers" [slashdot.org]
The original is lost, but I squirrelled away some choice quotes:
"From a business point of view, long hours by programmers are a key to profitability. A programmer probably needs to spend 25 hours per week getting coordinated with other programmers and comprehending the structures of the systems being extended. Thus a programmer who works 55 hours per week is twice as productive as one who works 40 hours per week.... A product is going to get out the door much faster if it is built by 4 people working 70-hour weeks (180 productive programmer-hours per week, after subtracting for 25 hours of coordination and structure comprehension time) than if by 12 people working 40-hour weeks (the same net of 180 hours per week)...."
"If you see one of your best people walking out the door at 6:00 pm, try to think why you haven't challenged that person with an interesting project. If you see one of your average programmers walking out the door at 6:00 pm, recognize that this person is not developing into a good programmer...."
Greenspun said the following in the Slashdot discussion:
"Most of the people at ArsDigita are young. They have no families. They have no personal reputation. Find me a 35-year-old who has accomplished a lot IN ANY FIELD, who has changed the world in some positive way, and who has never worked long hours. The articles I put on my various Web sites are not intended to help people who just want to live a quiet comfortable life (I'm not an expert on this). They are intended to help young people turn into Linus Torvalds or Richard Stallman or Dan Bricklin and Bob Frankston (Visicalc)."
"At ArsDigita we do tend to get fairly young people who are very bright. They want to do something that will impress their classmates from MIT or UCLA or Caltech or wherever. The key to successful management is to provide an inspiring goal that these guys and gals can buy into and then a working environment that lets them achieve the goal. It does result in some long hours but [at ArsDigita, at Greenspun's insistence] they have 5 weeks/year to recover. If they get sick of it they can always join a slacker company and work 40 hours/week."
"Let me say that I did not intend "Managing Software Engineers" to be the last word on the subject.... I don't want to be remembered for advocating a long work week. There is a lot more to the article and I certainly wouldn't advocate long hours to anyone who didn't love his or her job and wasn't learning every day."
(The banner ad for this page says, "Find a better job, NOW!" I tend to agree.)
Re:Agreed (Score:1, Interesting)
America was able to greatly increase its total productivity in the 90s but only by hugely increasing hours worked. Meanwhile, productivity per hour worked is much higher in Europe, even with short work weeks and mandatory four to six week vacations. The shorter hours allow greater quality of life and the time to pursue new interests.
The program text [marketplace.org] and audio [marketplace.org] can be found at marketplace.org.
Re:Hmm... (Score:5, Interesting)
The conclusion of the studies was that people become increasingly ineffective after 10 hours per day, and very ineffective after 12 hours per day. BUT - they don't realize it. If they are "motivated" they think they are doing fine at hour 16 or hour 20. Objective testing shows that they aren't.
And similarly, anyone can work one or two 16 or even 24 hour days. But after a week of 16s, or ever 7 straight days of 12s, performance again drops significantly.
But hey, since your project won't hurt anyone else if it melts down, go ahead and work those hours!
sPh
Some interesting figures (Score:3, Interesting)
I can't remember exact sources, but I'm pretty sure one of the published papers last year showed that you actively become less effective as a software developer (you introduce more bugs than you fix, etc.) when you've worked more than 48 hours in a week. There was very little direct benefit found to working more than the 35-40 hours that are actually in most contracts, and the drop in morale and loyalty is probably more significant.
In contrast, there were a few interesting case studies where software houses tried working with significantly shorter hours; I can't remember for sure, but wasn't one of them reported here a few months back? I distinctly remember one company (somewhere in northern Europe, IIRC) which trialled a 30 hour work week. Their productivity rocketed, as their staff came in, worked a solid three hour morning with full concentration, took a comfortable lunch break, worked a three hour afternoon also with full concentration, and then had time left to do anything else they needed. No-one spent the whole day calling the bank or landlord or writing personal e-mails, because they had time to do that stuff after work. And of course, the morale and loyalty of the staff were fantastic, with a near 100% retention rate after introducing the reduced hours.
Re:Prediction: you will get fired (Score:3, Interesting)
sPh
depends (Score:3, Interesting)
I've never succeeded in doing 15 hour days for any length of time. I spend at least 8 hours sleeping (9 or 10 when designing something hard) and 2 hours eating every day. That rules out 15 hours days right there. (I do a lot of design work in my sleep or half-sleep. I often wake up at 4am to do algebra on paper when I realize I can't handle the math in my head.)
Re:Yup (Score:3, Interesting)
What's truly astounding is that the same managers, who were at pains to hire the brightest people they could find, think that those same people won't figure out what a fraud that is.
Re:Hmm... (Score:3, Interesting)
At my university, we installed a computer-controlled train lab. It was the first semester of the course, so we students were put in groups of three "in order to be more effective software pioneers." My group was unfortunate in that one student dropped the class, so we were shorthanded. Then another student decided to focus on his senior project. So from a group of three, I became the only student in my group writing code.
I was the only student in the class with experience with electronics and device drivers, and several years experience with linux. So I got to be the volunteer sysadmin in addition to course assignments, and additional code that would be provided to the other students in the class; it was assumed that they would not be capable of writing device drivers, and these were outside the scope of the course anyway.
Long story short, at least 5 nights per week were tied up in that computer lab (the other 2 nights were long nights at a part-time job), keeping the machines going, performing backups, fixing windows and linux interoperability problems, and coding the drivers that were passed out free to the rest of the class. Since we were given keys to the lab, I came in any free moment I had, and worked until I passed out and fell out of my chair, only to be found unconscious by the professor the following morning. Then I'd get up and go at it again.
I got sick frequently, but came in anyway. I was in the only group that didn't have a working program to control up to 3 trains running the tracks simultaneously, and my code was errorprone and buggy. The other teams actually had to code failsafes for contingencies when my device drivers actually failed.
My attitude changed that semester, much for the worse. When repeatedly accused of being severely sleep-deprived, I responded with "Sleep is for the weak! It's an addiction! The addiction should be broken!"
But even the professor, for whom I was putting in so much effort, accosted me of pushing too hard, and getting nothing done. I was then enlightened of the cliche "diminishing returns"--you can keep putting effort in, but without proper rest, you'll get less and less back out.
On the other hand, this rather lengthy post (and its likely incoherent babblings) comes from the bleary-eyed eyes of someone working on a goofy kludge of socket programming in C to interface to Java applets. Thing is, I have no control of how many users can connect, so I must assume that there can be thousands of simultaneous connections.
Oh how I long for the days of sysadminning--I got more sleep as a sysadmin than I do as a programmer!
Ha ha, big joke... (Score:2, Interesting)
From personal experience, anecdotal for sure, I've written code during an all-nighter, which after a few hours sleep, was obviously not just wrong, but not even code, although it seemed perfectly fine at the time.
I left a job I had worked for 15 years because I was pulling 16-18 hour days for the last two years and, I was just discussing this with a friend a couple hours ago, didn't even realize it had happened. I was chugging extreme amounts of caffeine, going through a pound of Kona a week, and doing some serious damage to my own health with lack of exercise and fast food diet. If this is your manager's idea of how to _regularly_ accomplish things, then get the hell out. I mean it. Once managers realize they can pull shit like this all the time, they will! And guess who gets fair compensation for this, not you!
It is the result of poor management, particularly very bad planning. If there's some advantage your employer can gain by pulling all the strings, once, ok, particularly if it means you get compensated fairly or your employer stays in business, I can see it. But if they're doing this as habit, you seriousl are doing yourself harm by remaining staying and becoming a victim.
When I started my next job, after the one which nearly burned me out, I was shocked when my manager asked me why I was staying 10 minutes after five, "just a few things", his response was, "they'll be there tomorrow, go home, get!" It really was a different world, where work got done in 8 hour days, and planning made it work. Too bad new management came in and fouled it up and sunk it, but that's another story.
Balance is critical (Score:2, Interesting)
I own my own company in a highly competitive IT field. Our company is surrounded in our regional market alone by many other small businesses who provide a similar service, at a cost that we've found is typically more expensive to the end customer than us. Given that I'm the owner of my company, I suspect you might take the following with a grain of salt - I'm biased... =)
Still, we have recently hired a number of employees and many of the potential candidates were from those same competitors. Often, they were being paid less than we were offering, and worked long hours without much reward for those hours. Two of our first employees were from a direct competitor who sounded almost identical to the environment you describe.
In our company, staff get all stat holidays, one full week from Dec 24th to Jan 1st, with regular hours (regular being approximately 8 hours with most people starting anywhere between 8am and 10pm and finishing anywhere from 3pm to 6pm) and usually a couple of weeks holiday through the year.
So what makes our company able to do this when theoretically our competitors are twice as productive because of the extra hours they work employees? Our employees LIKE coming to work. We're a community and people want to be there. We involve people in decisions about how they do their work, and we insist that people take time off. Yes, occasionally we ask staff to work long hours - and a long day for us is 10 hours - but I then insist they take a long weekend or some other time immediately to reflect that extra effort. Not six months down the line when the manager has forgotten the extra time and gives it out begrudgingly, but when it will be felt and appreciated most.
We also practice continuous improvement. If we do the same thing over and over, we look for ways to improve the process so that we can do it in half the time so that those who are working don't get bored, and can finish off monotonous tasks more quickly. We encourage staff to take courses to further their skills and allow them to move around in their jobs.
By no means do I think we're perfect - there are lots of things that we do poorly. But for the most part, we know what they are and we focus on them. And I don't think we're alone in our business philosophy. There are companies out there that don't treat employees like cattle but they're not always easy to find as so many companies sound perfect during the interview. See if you can interview the company employees before you're hired and ask them to be frank with you. Sometimes even that doesn't help if the company preps their employees, but it might give you some idea of the mentality of the company. If possible, always get to your interview at least 10 minutes early so you can watch the dynamic of the office that you're looking at. It will tell you a lot. I still do this when sizing up potential clients because it will help me determine what kind of client I'll be dealing with.
Anyway, good luck with your job, whatever you decide to do! But whatever you look for, to me the best way to a good comfort zone is always creating the right balance both mentally and physically. Without balance, something invariably begins to break down.
Re:Hmm... (Score:3, Interesting)
I certainly did not like my programmers working extended hours; at least not routinely. It made them tired, irritable, and a pain in the ass to have around the office. The code got sloppy, too.
As for deadlines, I found the way to achieve them was to have the deadlines set by the coders and tie their bonuses to the quality of code and ability to deliver it on time. When I did that, the deadlines were met and the bugs largely went away. Obviously, you need to know enough about the technical aspects of the project to tell if they're blowing sunshine up your ass.
I found that to mitigate extra hours, I let the programmers work from home via VPN and I kept track of the extended hours to comp them extra time off. To be honest, some of the most productive days had all my coders at their houses VPN'd in and conference calling to work out issues. Some worked at night, some early in the morning. They worked out their stuff between them. As long as good code flowed, it didn't matter.
Not bugging the programmers is the number one key to good code.
I never felt that the programmers really had a large enough equity stake in the company to justify working extended hours.
It's a professional thing. Pay people well for doing their job well. Give 'em a cost of living raise for simply doing their job well. After all, that's the expectation; it's why they're paid. They shouldn't make less each year for doing a good job. Give 'em a raise as the market and their knowlege makes their talent more valuable. Bonuses are for extra effort. Can be equity (if it's worth anything). Can be more vacation if cash is short. Cash is good too.
But long hours with no real equity stake? Screw that. Sounds like someone has some project management issues. Get out as fast as you can.
Just my 250,000 pre-IPO options (or $0.02, whichever)
And lay off the spelling, it's late and I don't care.
Mismanagement (Score:2, Interesting)
This is the part that has always amazed me. How can they ask you to do something this stupid with a straight face?
My last boss caused me great pain with such stupidity. One of my Debian buddies sent me a good explanation [apa.org] after I spent the afternoon complaining about it. That PHB did not even understand that laying me off was actually a reward. My nerves are finally starting to recover and I should be able to kick-ass on my next job ;-)
Understand your ignorance (Score:2, Interesting)
Do you really know what's going on with the competition, or do you just believe what the suits tell you? Is the pricing strategy correct, or are the Marketing people on drugs?
The problem we all face when we are in your situation is that we are operating in a vacuum. I've been a coder my whole life, spent the last 10 years in upper level management positions. Let me tell you something profound: You do not know what upper management knows. They will never tell you the whole truth. Therefore, you cannot make a rational determination as to whether this request to work overtime is reasonable and thoughtful, or whether it is just the last frantic thrashing of the whale's tail before death.
I've been coding for 32 years, I've started two companies, worked for many. Here are two general observations that may or may not apply to your specific situation:
1. If you are working massive overtime, do so because you are starting a company on the side, not because your current company has understaffed the department.
2. It is easy to believe in your own importance, and that you can make a difference by working OT. Sadly, you probably won't make any difference at all.
Hope this helps.
Negative produtivity (Score:1, Interesting)
Re:Hmm... (Score:2, Interesting)
Re:Nah (Score:2, Interesting)
It does not matter how long I am at the office. I can only deliver 6 hours of code. And that's if I am well rested.
If I'm very tired (less than 6 hours of sleep) then the amount of good code goes to zero.
I know that because the next day I spend 6 hours fixing the code I wrote the day before. So in actuality, in 2 8-hour days, I produce only 6 hours of code.
When I come in on a Saturday like today, I'll be here for 7 hours, but plan on coding only 4. Why? Because I know that I won't have to screw with that code ever again, and in two-three years it will be chugging along happily without a single failure.
Oh, and it will be properly indented, properly commented, and have failover redundancy, event logging, and a fully detailed technical paper in html.
And that is what my company is paying me for. Not face-time.
Re:Hmm... (Score:3, Interesting)
That last one is the real killer.
Whenever I see one of these if-you-aren't-sweating-you-aren't-working projects, I can guarantee that they will spend a lot more time fixing bugs than is sane. Of course, many of those bugs won't surface until the last part of the project, so it looks like more progress is being made.
This is the same mistake a lot of people make with credit cards. For the first few months they have them, they're rich! And then suddenly, they're screwed; all their income goes to interest charges, so they're suddenly poor. Some people will make minimum payments for years; some will just declare bankruptcy; a very few will get a clue, pay off the debts, and then never use credit cards again.
Re:Yup (Score:3, Interesting)
There's a difference between telling an employee to work more efficiently throughout the day (your union example) and telling an employee to work longer than is reasonable. On one hand, yes I do believe work should be rewarded, but on the other hand, you don't want to create an environment where long hours are expected and considered reasonable. Work should not have to be an employee's whole life (yes, I'd define 60 hours per week as "your whole life"), and an employee who wants to have a decent life outside of work shouldn't lose out because other employees either don't have or don't want a life outside of their workplace. Around the places where I've worked, unless something was breaking terribly, a sysadmin was expected to work 40-45 hours a week. And there's no reason why this shouldn't be the expected.
Always, always remember: the company is not more important than the employees. We heard a lot of bullshit during the dot-com era about how the employees needed to sacrifice everything to advance the company.. somehow it was reasonable to expect 80-hour work weeks, weekends, all because the company was in a groundbreaking new field and it would make all the employees rich.. and we know how empty those promises ended up being.
I guess my (admittedly rambling) point is that employees should have the right to expect the 40-hour work week. Some people might want to work a little longer for extra pay, and I have no problem with that. The only things I fear is that then this becomes expected for other employees, and they are pressured (or simply fired) for not upping their own hours.