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.
Eh? (Score:2, Funny)
Hmm... (Score:3, Interesting)
Time for Physical Exercise (Score:3, Interesting)
Oh, btw, hope you don't smoke, or all bets are off.
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
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!
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.
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.
Yup (Score:2)
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:Yup (Score:5, Informative)
No, eight hours was defined as a work day in the US because of the efforts of the labor movement, beginning the middle of the 19th century and, after a great deal of struggle, culminating in FDR's passage of the National Industrial Recovery Act, which was then struck down by the SCOTUS, and then partially replaced by the Wagner Act. The eight-hour work-day came at the expense of workers who were beatened, imprisoned, and killed trying to win it.
Re:Yup (Score:3, Insightful)
As long as there is no industry or regulatory standard for how long people in a given job in a given industry works, and as long as sales people get commissions for promising more, faster to customers (and not getting contracts unless they do) then more, rather then fewer, jobs will be in permanent crisis mode. It's a sort of inflationary economy. Only when there is universal expectation that any given worker is going to work 40 hours, then bids will go out with that assumption. Otherwise, there's a race to hire only those who can work 50, 60 or more hours a week - and if you can't, you get pushed out of your career by someone with no family or other life outside work.
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.
Re:Yup (Score:2)
Strategic thinking will not happen.
Tactical decisions will most likely be severely flawed.
In short the most important factors for success will simply go out the window.
My advice: Leave this company now. There is nothing to be gained by staying. You do not own them any loyalty if they are willing to run you into the ground. While you are still fit and healthy you have a much better chance of getting a new job than after the first breakdown. Such a breakdown can take years to recover from.
Re:Yup (Score:3, Interesting)
Um...do you live on a planet where programmers are paid overtime?
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.
I don't know if they affect code quality... (Score:3, Funny)
Re:I don't know if they affect code quality... (Score:2, Funny)
Ho would have thunk it?
I think I'll coin a new phrase:
Illiterate by /.
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?
Re:Agreed (Score:2)
OK, I admit I don't actually approve of that point of view, but it's the attitude many companies take.
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.
Re:Agreed (Score:3, Informative)
Ever heard of an unenforceable contract term?
The EU working time directive trumps the language of the contract. In fact trying to put language in the contract might be used as evidence against the management at a tribunal.
It would be like adding a contract term in the US that said the employee waives rights under the equal opportunity laws.
Labor law is taken very seriously in the EU. Overall the costs of disputes is probably less than in the US however because jury awards in the few types of case allowed in the US tend to be much higher than EU awards.
Re:Agreed (Score:3, Insightful)
Actually, in France and most of the EU, the judge will find against the employer in that case. You see, the French introduced the 35-hr week not as a quality-of-life thing, but in an attempt to counter the chronically high unemployment that France has experienced in recent decades - if people work fewer hours, the logic goes, then more will need to be hired. If an employer demands extra hours, the government doesn't care if the worker is exploited or not, what matters is the employer is ignoring the government's policy, and it's not tolerated.
Unfortunately, these laws have had the opposite effect to what was intended. Because it is so hard to fire employees - for good reason or not - employers are reluctant to hire anyone. French unemployment is been stuck at around 10%, and Germany's about the same. In the US and UK where it's easy to fire people, the risks of hiring are much lower, and unemployment is closer to 4%.
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.
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: Agreed (Score:4, Insightful)
The average person needs 8 hours of sleep a night. With 15 hours of work, that leaves one hour(on both ends of the sleep cycle, combined!) to shower, shave, and commute. Granted, many people can go with less, but over time it will take a toll. 15 hours+ is fine in the rare extreme circumstance, but not as an everyday thing. How many people at this place will get fired for falling asleep on the job? Quite a few. And several others will start getting sick from the long hours, junk food eaten to stay up... In todays job market, leaving the company may not be an option...
Re:Agreed (Score:5, Insightful)
Development work, therefore, is done in the 16 hours/day that you're not there. It will therefore halve your output (in terms of solutions to problems) if you're only not there 9 hours/day. If the job actually demands 15 hours/day of sitting at the keyboard working on it, it's data entry, not programming, because you don't have enough time to think about the project.
I generally get to work with my head full of ideas, and leave when my head is empty and I have no more thoughts about the project. (Actually, I'm lazy, and leave a while afterwards. But I stop getting anything useful done when my head is empty.)
Debugging, on the other hand, works differently. The problems are small and self-contained, and your time is spent searching through the codebase, not thinking about how the project should go. There are a lot of bugs you'll only find by actually staring at the code, because the bug comes from some code not doing what you think it does; thinking about what is does won't help. There are still bugs that you won't find until you relax, though, so you can't go on forever. It's somewhat reasonable to have a 20-hour day on occasion, where you're fixing a lot of things that don't quite work, but you won't improve the functionality of the project much, just whether it works or not.
"That's a good question. I'll have to sleep on it." (Three weeks pass) "Why haven't you answered my question?" "I haven't gotten a chance to sleep."
On the other hand, a 15-hour work day could be reasonable if your work has really comfortable couches...
And next on Ask Slashdot! (Score:3, Funny)
Re:And next on Ask Slashdot! (Score:2)
That depends if you're optimizing for speed or for size.
Re:And next on Ask Slashdot! (Score:2, Funny)
"Does steller objekts really emmit lite?"
and
"Do unoptimisd code realy run slowerly?"
Walking Papers (Score:5, Insightful)
There's no excuse for an employer to consistently demand 15+ hour days and weekends. Once in a great while, when an important deadline is coming, sure it's a reasonable request, but a consistent basis? No way man...don't let yourself get trapped into that. You'll burn out and find yourself embittered against working at all. (I'm speaking from experience)
It sounds like this company is a poorly managed failing startup and probably isn't long for the world anyway. Quit while you're ahead.
Re:Walking Papers, body bags (Score:2, Funny)
I got a better idea: Go in there with a loaded shotgun, blow away the receptionist, your boss, and whoever's at the water cooler, and then turn the gun on yourself. Your message will be heard loud and clear all over the evening news, trust me. Also, it's very important that you kill yourself, or the press will paint you as some kind of deranged office killer without mentioning the note you've left on your dresser stating the 15-hour day made you do it.
Wait, you don't work where I do, do ya? Nevermind everything I just said if you work in Seattle.
Good luck on the rampage!
Yes. (Score:2)
Just quit. (Score:5, Informative)
Sure, sometimes coders spend a lot more time then that on their job, but that's because they enjoy it, because they want to spend that time working on code for their job.
If your boss is demanding you work 15 hours a day, quit.
Will it affect code quality? I don't really know. In the short term I doubt it, actually. Will it affect your quality of life? Absolutely. Will it affect employee satisfaction? Probably, and down the line that will affect code quality. If you don't like your job, you're code will definitely suck.
Prediction: you will get fired (Score:5, Insightful)
Executives don't like reality. They are all about wish fulfillment. When your project(s) are not completed by their deadlines, you will be fired. You will be the one who has to pay, because you were the one repeatedly pointing out that you needed more resources, given the requirements and deadlines. You contradicted your executive's worldview. In any competition between reality and an executive's world-view, the executive wins, in the short term. Reality always wins in the long term.
Another Prediction: you will get fired ANYWAY (Score:4, Insightful)
Re:Prediction: you will get fired (Score:4, Informative)
They were so certain of this that I gave up debating the topic, and when month 3 rolled around, lo and behold, NO SHIPPABLE PRODUCT. 2 of the 3 developers were asked to resign with severance pay. I will NEVER accept that kind of shit from management again-- next time it'll be "I work 8 hours a day, and if you don't like it-- too bad!".
Re:Prediction: you will get fired (Score:2)
Re:Prediction: you will get fired (Score:3, Interesting)
sPh
Good Resource (Score:5, Informative)
Here's a good reference: Forty Hour Week [c2.com] on c2.com, which seems to be the best web authority for Extreme Programming discussions and patterns.
Give it a gander.
Of course it hurts quality (Score:2)
What you boss wants is cheap software. He wants a few people to stay all night and write it quickly. You can make a play that cheap software is only cheap in the short run. You can explain that the reduced customer sastisfaction and maintanence costs will prove that doing it right the first time is a better idea.
However, I'm guessing it won't work. Your boss probably knows what he's getting and he wants it.
Vanguard
Get a new job. . . (Score:5, Insightful)
GET OUT WHILE YOU STILL CAN!!!
I mean good lord man, you're telling me every symptom of every business that I've seen go under locally. The whole "balls to the walls" syndrome is often more of a "we're cutting budgets that we really shouldn't" syndrome. I fully expect that you'll find that the same managers that are willing to have YOU (not them) put in 15 hour days are also the ones willing to say "sure we can do X+Y at the budget for just X" to his higher ups just to look better.
Re:Get a new job. . . (Score:2)
2 good friends of mine programmed for a local game firm. They worked manditory overtime and were laid off at the end of the project.
Spend The Time Wisely (Score:5, Insightful)
My advice would be to use those seven extra hours in front of a PC to tidy up your resume and get it out there. You are going to be looking for a job soon enough, you might as well get the headstart.
Ask yourself, how many dotcom tales of people agreeing to work without pay for a while; work long hours; all the rest of it, you've heard. Now, how many of those companies actually survived by doing that? Next to none?
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:Spend The Time Wisely (Score:4, Insightful)
This guy looks like he's walking into a sweatshop environment.. Long hours, little recognition, bad project planning.....
It's the bad project planning that really gets to me. It's the expecting the employees to be slaves and happy about it. It's the sinking ship, and you better find a raft now feeling to this whole scenario that has me wanting to scream.
- Get you resume out there NOW!
Either everybody burns out before the project's finished, or they get fired after it's finished, or they're going to expect you to do it again with the next project.In either case, you'll be short a job, a life, or both.
Re:Spend The Time Wisely (Score:2)
Now ask yourself how many of those unemployed coders would be more than happy to take your job when you get fired for not putting in the overtime?
I'd say it's funny, but it's actually really depressing. During the boom, people were worked to death because of the emphisis on short-term stock gains (lower employee costs == higher profits.) After the bust, people are being worked to death to try and keep companies afloat (lower employee costs == longer run-time on fixed ammount of $$)
It's very hard to challenge what people believe to be true, be it management theories, religion, C++ vs. Java, whatever. All the statistics, reports, copies of Peopleware you wave at your managers won't make a difference if they believe "more work" is the magic bullet.
And unfortunatly, sometimes it's the only bullet available. Time Slip = Lost Chance at Revenue, Feature Slip = Lost Customer, etc.
ObRandomOnTopic: My company sent us all an email earlier this week saying the upcoming long weekend was to be treated as a "normal weekend," i.e. you are expected to be at work. Feh.
Some good some bad (Score:2)
Sometimes putting in the extra work is worth it; but, if the end of the project is a long way off, DONT.
If you put in the extra hours now, will it reduce the extra hours later? Again, if so, fine, otherwise, NO.
Why? Because if the project manager gets it in his head he can have 80hr weeks out of everyone he will plan them that way. It is very easy to become burned out and few managers know how to properly handle it to prevent that.
Devils Advocate (Score:2)
What about the many stories of caffiene-addled coders working 36 hours at a time, and sleeping under their desks, coding under pressure to get the job done on time? See here [jwz.org] for a good one.
I mean yeah, most normal people want to work 8 hours a day. But others want to be supermen, and are willing to put in long, long hours of work to beat the competition.
Get out while you can (Score:5, Insightful)
Don't walk away from this situation, run.
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:I am not owned by a company. (Score:4, Insightful)
If I were in a more cynical mood, I would suggest that you contact a lawyer and see if "balls to the wall" was evidence of a sexually hostile workplace.
Personally, I think software development management is of generally poor quality. This is due to a combination of management ignorance, poor engineering practice, the intangible nature of the product (its much easier to explain sensibly why designing, tooling up for, and manufacturing a widget takes a long time), and underestimation by the rank and file developer. If I had the magic bullet for this problem, I would not still be a mortgage-holding software developer, I would be a very highly paid consultant and regular pundit quoted in the trade rags.
I'd walk out the door too, if I knew I could.
Tip for the youngsters: Buy less house than you want. Have six months salary in the bank at all times. Then you can storm out in high dudgeon like antis0c suggests...
Long hours... (Score:2)
How it affects code quality - don't know. In my case, if I work for around 3 days for around 19 hours and WORK seriously most of the time, that might work, but after that there is a steep decline in quality and productivity. If I HANG AROUND at work for the same amount of hours per day, I can do it for weeks.
So, I don't have an answer, but I quess it depends strongly about whether you need to concentrate on what you are doing a lot or not.
Quid pro quo (Score:2)
Above all else, remember, you can't do this forever, 15 hour days don't mean twice the productivity.
I heard a story about someone on deck at a big 5 consulting firm. They worked 100+ hour weeks and all to make partner, and eventually worked until a lot of the systems in their body up and quit. Just overstressed for so long, everything started to shut down at once. Went way over the million dollar lifetime healthcare cap (the firm has to pick up all future medical bills.) The guy made partner and recovered but became a medical case study.
QUIT! (Score:2)
What I would do is not make a big deal of it but make sure you do your 8 hours and go home. If anyone tells you to do more hours tell them politely no. All the time look for another job.
I assume the owner is the first to arrive and the last to leave?
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.
Of course it does (Score:2)
No - really.
Anyway, my company recently changed our development style to take some pressure off the engineering staff. Whereas previously, 14 hour days were somewhat the norm, those have now been seriously reduced. Those with famlilies actualy get to see them. Those without, get to play Final Fantasy X until 4 AM. Overall, moral is better, and there's not been a signifigant change in output - and the quality is improving.
The best option... (Score:3, Informative)
Back on topic, working 15 hour days WILL affect your code quality, not to mention your quality of life. Different people have different ways in which they work best, and sometimes a long coding session can work wonderfully, but over the long term it will result in frazzled nerves and bad code.
If he's expecting you to work 15 hour days, you need to let him know you should have twice as many people working 8 hour days instead. If he protests, drop that job like a bad habit. You'll only be hurting your health and sanity if you stay.
Sometimes long hours are just fine (Score:2)
As a rule I figure you can sustain two or maybe three major bursts of 100 hours a week. Each burst shouldn't last more than 5 weeks. I once did a ten week burst and it nearly killed me. Once you go over 5 weeks, you'll get into serious counter-productivity.
Its also important to have a good reason to do so. If your company doesn't have the cash or revenue to hire more people and needs you to put in the hours to get a revolutionary new product out, that's one thing. If its poor planning or management that causes the crisis, it will be much harder to motivate people to put in long hours.
yes, but don't worry. (Score:2)
sue the company for creating a hostile work place, and making sexual innuendo, then retire.
this depends. I have seen a 'crunch time' where long hoiurs where out in to meet a deadline. This will work, on ocasion. it will fail long term.
Look at Tivo. in order to get a product out befor the competition, they had to rethink there process, and pretty much work everyday to meet there new deadline, and they did it.
now those where people that most, if not all, got a piece of the company, so thats strong incentive.
However, if you are suddenly expected to work 15 hours a say, and weekends as part of normal operating procedure, I would contact the labor board and see if they can bring pressure onto the management and keep you anonanous.
This is why I would like to see software developers orginize. If you think you can get support, start a union and strike.
they can replace you and that impact will be a speed bump, but if they have to rehire everybody, that would be chaos, and that is where the worker has the power.
Long Hours don't work - simple answer (Score:3, Insightful)
Now if we step back from the coal face and take a longer view the question you have to ask is do we expect our programming staff to pull insane hours every project? Hell no, they'll leave or in an even worse scenario they'll stay and their productivity will drop below the Z. Your fella sounds like he's either new to the game or just wrong for the job. Your can't afford to burn out a development team per project even in these down turn days.
Programming is an essentially human activity and to get the best out of your real software (the fleshy pink stuff) you need to take a long term view, but I can understand how their are many managers out there who think productivity = longer hours and thats it.
So use the simple arguments, people who are tired make more mistakes, are less likely to confer with peers, get upset when confronted or corrected, get angry more quickly and generally do a bad job (no surprises here).
Joe.
Who cares? (Score:5, Insightful)
Get a life. (Score:5, Insightful)
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.
Forget about code quality. Forget success. Your life is too short.
There's nothing wrong with having a modest carreer, and enjoying your work. But just be straight about one thing: when you are 60, you will in all likelyhood look back and see it as a waste.
People who are happily married live longer. Having a relationship takes as much time as a full time job .
You cannot have a relationship with your partner on 20 minutes a day of discussing the bills, the chores, or over a sandwich. It's a full time commitment. It takes spending quality time together, and not just quality, but quantity also.
Wanna have children? You think they're going to turn out great if you're never there to be there for them? You want them to feel loved, and nourished, and mentored? Then you have to be there. Not at work, not on business trips, not at the mall. But there, with them.
You want your parents to feel loved by their children (ie. you) when they grow old, and you're all they've got? Then you have to spend time with them.
Time is all we have. And all we really have, that really counts, is each other.
Geeks are probably the last people to get this, but if you really knew that a truck was going to hit you tomorrow, you would find that your real desire would be to spend the time with those who are close to you. Your job, money, and gizmos are meaningless by comparison.
Work, and prosper. Don't be a slave. Have balance. Be sweet to each other. Don't let some stupid and misguided manager tell you that you have to kill yourself to "succeed". Success is measured in happiness, not paycheck or accomplishments.
If you have the talent to work on class projects, then fine. If you don't, then just let it go. You can still be happy. Truly happy. Just open your eyes and see that life is more than a resume. You have the capacity to love and you can learn to use it to create happiness.
Be true to yourself.
Re:Get a life. (Score:2)
OTOH you should see how happy a couple of million would make me...
Do you pine for the nice days,... (Score:2)
If you really enjoy what you're doing, you're probably already working 15 hours a day and weekend.
If you don't enjoy it, just quit and do something else.
But please stop whining !
Bad management (Score:2, Informative)
Peopleware (Score:3, Informative)
Fuck the Company (Score:2)
Bad project management? (Score:2)
Actually long hours are good project management but the project manager needs to understand that there will be a huge loss in effectiveness and the more overtime hours somebody works, the less effective they are. If that is not accounted for, that is bad project management.
The flip side (Score:2)
I believe that working continuous long days and weekends ultimately decreases long term productivity. People get tired, they get frustrated, they make more mistakes and while they may spend more time 'on the job', their actual productivity tends to slip. After the first spike in productivity due to more time 'on the job', productivity will start to even out, even with longer work days, and eventually start to decline. So, this is usually not a good way to go.
Second:
But...there are times when increased work time is a tremendious benefit. Having the opportunity for contiguous thought and work for example. I know I've worked some 36 hour days to get massive work accomplished on a project. Now this was on my own accord and when finished I had time for significant down time and 'fun' work, but it was a long day, and was very productive. Second, with the proper motivation even medium length work spikes can yield high production. This production isn't without costs however. As another example our company asked engineering to work 10-11 hour days and Saturday for 3 months in prep for the rollout of our first product. However included with this, were many consessions made by management including: Additional time off, bonuses, free dinner & beer (yep that's right), flexible hours, the ability the throw nurf balls at management (who was there late too) and the realization that we were all working for a common goal. In this case we weren't under the gun due to crappy planning, but we wanted to get to market fast and everyone agreed and stood to benefit. Another example of long hours paying off.
So I guess my point is that long hours aren't enherently bad. They have to be taken in context of how they're used, how they're brought about (motivated), and what the end goal result will be. It should also be noted that in each case of longer working better, it also cost much more. Explain that in order for productivity to actually match what they expect, they'll have to take into account that it will most likely cost a few orders of magnitude more to due it.
Re:The flip side (Score:2)
That all sounds very reasonable. I went through a similar thing at a previous company.
This guy sounds like he's working for nutjobs, though. His boss sounds like the Ross Perot in the SNL skits -- "I'm a powerful man!"
Re:The flip side (Score:2)
Next Policy To Be Implemented (Score:4, Funny)
<balls to the wall> (Score:2)
when i party, i go balls to the wall
</balls to the wall>
Use external libraries and reduce requirements (Score:2, Informative)
There are bound to be areas where you're re-inventing the wheel. Do a freshmeat search and find something which does the work for you.
You might be able to remove entire sections of development and the areas replaced will probably have extra features you'd never have added.
I think this approch should be taken more often.
If the code isn't precisly what the software's about -ie where it adds value, you need to justify not using external code.
Remember, if you code remains in-house you can use GPL'd code.
Also, make sure all the functionallity really is needed. Drop any extra work to improve flexibility, -your guesses will probably be wrong so spend the time once you know what the new features are (this is just XP).
The main effect will be... (Score:2)
Of course the work done before it finally all comes crashing down will be of low quality, with obscure problems and no documentation.
Bottom line: While there is usually no way to speed up a delayed project, there are quite a few ways to delay it even more or make it fail completely.
Good literature for the general topic: Brooks: The Mythical Man-Month, Addison Wesley
Very Simple Answer (Score:2)
a) Concentration is reduced
b) Morale is reduced
c) Quality is sacrified for "delivery"
d) Deliveries become bug riddle pieces of crap
Been there, done it, got the T-shirt. At an absolute crunch you work the weekend, you might pull 50+ hour weeks for a while BUT....
YOU MUST THEN REST... take extra days off to recharge. Or your immune system becomes weaker, you are at more risk of being ill, and in an under resourced project that is a disaster.
Work 8 hours a day, review properly and I _guarentee_ that from my experience after three months you will be better off than if you work 15 hour days and weekends for those three months.
The productivitiy will go down (Score:2)
Let the managers pay for their own mismanagement. Get a job elsewhere.
Good luck.
Re: (Score:2)
Re:Thoughts, including salary vs. hourly (Score:2)
Which reminds me. Aren't there supposed to be still a lot of unemployed programmers in the US? (FX: Everybody nods.) So shouldn't it be relatively cheap/easy for the boss to increase the programming staff a little at a time over the next year or two?
I know all about Brooks' Law; this won't help your immediate "crunch" situation. But going forward with new projects you need the right number of highly qualified programmers--why not start as soon as possible?
What are you getting out of it? (Score:2)
And the kicker: What does the owner of the company, who is issuing this order, get out of it? Does he get richer while you get nothing? Is he going to take a bunch of personal time off when it's done while expecting you to continue working normally?
I think where I am going with this is obvious: Can you tell if you are being exploited or working in your own best interests?
If you and your team reasonably share in the rewards of the project being successful, then that is a very different situation than if you are giving up part of your life (which you can never get back) to your detrament for the sole purpose of rewarding someone else. Given the nature of employment in this modern era, there is no 2-way street or life-long contract anymore, so you have to be looking out for your own best interests as nobody else is going to.
I've worked in such situations in the past. When I was young, I felt I needed to do whatever it took to keep my job. I was afraid. I'm older now, and I've developed some common sense and a spine. I won't let my self be exploited. Since the original poster didn't elaborate as to the circumstances, I can't say if the situation is exploitave. But if it is, I say leave, and leave now. Your sanity, health, peace of mind, and precious moments of life are worth too much.
I was just reading Feynman. . . (Score:2)
The computer didn't get tired and start making mistakes. The "girls" did.
Do long hours effect the quality of code? Well Duh! Does the Pope shit on a bear in the Vatican woods?
Will anything in this thread help convince your boss the whole thing is a bad idea? Nope.
Is it time to bail? Yup. Do it now. The people telling you you're just going to end up fired anyway know of what they speak.
KFG
Don't do it (Score:2)
For years, working overtime was just part of the job. I then started suffering from severe stress related problems. I have a new policy. I don't work extra hours for the sake of working extra hours. Period. As other intelligent people pointed out, life is too short.
If your manager can't handle that, find a new job, unless you want to do it. Yes, your productivity will go to hell, yes, code quality will sucks, but who cares. Your life will suck, that's what matters. No job is more important than your happiness.
It definitely does... sometimes. (Score:2)
As for your boss... If my boss would use such language, I'd suggest he speak for his own balls and I'd give him the finger instead. I'll work such ridiculous hours for pay, or if a critical project that is running late requires it. I do have that much loyalty for the company. But I'll be damned to work harder for better profit margins, bigger paychecks for company presidents or increased shareholder value, of which I can expect to see exactly zilch.
Long hours wouldn't be so bad.. (Score:2)
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.)
And added compensation? (Score:4, Insightful)
Work _80_ hours a week and you're only making _$20_ an hour. You're getting robbed if you're really worth $40 per.
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.)
Hows this? (Score:5, Insightful)
Surprised no one has mentioned "Death March" (Score:4, Informative)
Death March: The Complete Software Developer's Guide to Surviving 'Mission Impossible' Projects [amazon.com] by Ed Yourdon.
Buy, borrow, or spend a few minutes in a bookstore reading the first 2-3 chapters, where Yourdon describes the four different type of death march projects, the prersonalities and politics surrounding them, and what your options are.
What you'll read there will likely be the same sort of advice you're getting here. Yourdon's presentation is a bit clearer, though, and he raises a lot of good points about how to make a decision with regards to whether or not you'll buy into a death march project. The middle section of the book details how to survive on such a project if you do, indeed, decide you're going to take it on.
At the end of the book is "Death March as a Way of Life." The long and the short of it is that these type of projects are increasingly common. If the project fails, then then it's your fault - you didn't work hard enough; the next batch of folks will no doubt be harder workers than you were. If you succeed, and ship on time, you'll just show management that death march projects work. Either way, you'll be in a job where every project requires increasingly superhuman efforts.
Better to decide if you want to deal with that now, instead of trying to do so after a few years of insane workloads have destroyed your marriage, health, and/or mental faculties.
Simple Math (Score:3, Insightful)
Me? My answer would be 'fuck no', but I do realize not everyone is a position to say that.
Re:Coders VS Management... (Score:3, Insightful)
Perhaps management should listen to the developers when creating schedules and product release dates, instead of the marketers?
Re:Coders VS Management... (Score:2)
Of course, if you piss your staff off too much, or work them too hard, they'll leave, the projects won't be pumped out in a timely manner, and the business will still go under.
15 hour days and weekends is unreasonable to the point of being a joke.
Yes code quality will suffer. Perhaps not in the short term, but in the long term, most people simply cannot keep up those sorts of hours. It quickly becomes a long, hard slog, and people become demoralised. An unhappy worker is an unproductive worker. A tired worker is an unproductive worker.
Coders need to be able to concentrate. That becomes increasingly more difficult the more tired you become. After a certain point, the code you produce will be of sufficiently poor quality that you would do better not to write it at all.
I have a family to support, and a mortgage and loans to pay, and my reaction to that would still be hostile in the extreme. I would explain, rationally, why I thought that working such a schedule was a bad idea, both personally and for the business. If and when that failed to make an impression, I'd quit. There's more to life than work, and there is always another job out there.
Cheers,
Tim
Re:Coders VS Management... (Score:2)
RUN
Re:you're in the wrong place/country/job (Score:2)
I'm afraid that you've been misinformed.
The law, at least in the UK (and we only have it because of the Working Time Directive that we must implement, being a Member State), is that you cannot be forced to work more than 48 hours per week averaged over a 13 week period.
Of course, my contract contains a clause saying that I waive that right, and I'd be very surprised if there were many IT firms in the UK that didn't have that sort of contract.
So yes, we do have laws, but don't feel quite as safe as you seem to.
Cheers,
Tim
Lawyers to management... (Score:2)
Quitting might get the message across. But, management may choose to be oblivious, that's their perogative.
Also, you have to realize that "successful" may mean something completely different to management than it does to a developer. Successful to a dev means the nasty bugs are gone and the product performs the intended functions. Successful to management might mean that they finally got the thing out the door just in time to capture a high-profile customer that was being romanced by the competition, and we can worry about the bugs later.
There are lots of people who are happy to put in 80 hours a week (Microsofties for example) but it doesn't sound like you're in that position. Putting in overtime because you love your job is one thing, "required" overtime is different.
Your well-worded voluntary resignation, quoting the "15 hours a day," and CCd to your State Attorney General will get the message across.
Re:Lawyers to management... (Score:2)
CC that to the attorney general. then when someone mentions it, say you wouldn't complain if you got more money.
Run your career like a business.
Re:Sometimes it is... (Score:3)
Working long hours is fine in the short term. Deadlines, unexpected problems/projects, etc. all require it, and it's justified. But most people need 2 days off, and need to not be at the job 12+ hours a day, every day. It's bad for you, and your code quality will suffer.
Re:Sheesh, this is 4th grade stuff, Cliff (Score:3, Funny)
Re:Being a college student.... (Score:3)
Maybe for you it can be easily achieved, but it is not normal. nor is staying up for 20 hours straight.
8 hours of sleep per day is the natural average, and basically the rule. if your cumulative sleep average dips below 8 hours a day, your body WILL make up the difference with added sleep later on. Sleep debt is very real, and can be tracked even over long periods of time. Even drugs don't help. Stay up for a few days on speed, you WILL get extra sleep until you catch up.
Now.. I'm not saying that there is no such thing as long, long productive binges.. when you get into "the zone" and just go and go and go, and only stop when your body literally cannot keep going (ie: low blood sugar, can't keep eyes open, etc). And as much as everyone THINKS this is what programmign is about.. it's not.
The thing about lack of natural light causing a 26 hour day or whatever it was came form a sleep experiment 30 years ago or so where they set up a test group in a deep cave, where there was no possible trace of day/night cycles. They did observe that people seemed to be on a 25 hour cycle.. but it was determined this was due to the artificial lighting being on a weird cycle. It's not normal or healthy.
One could also argue that how we would behave without the sun is a useless argument, we have millions of years of evolution behind us with the sun there.. it was there before us, and will be there after we are gone. our day and night cycles are completely based on the way the earth works.. not some alien like weird timescale.
It's funny you should mention emergency physicians.. they are one group that DOES do this, I think rather frequently. They will often work 24 hour shifts, catching a nap if things slow down. Unfortunate but true.
Also, you are in College. This is not a permanent situation, and you are most likely still quite young, and your body can heal and deal with less sleep easier than it will be able to a few years form now. I'm saying you might change your mind about rediculous working hours when you are trying to live a normal life 10 years from now.
Re:My last crazy night was before 9/11 (Score:3)
Luckily
I have now had the time to reflect on what I was going to post and here is the revised version.
You typify bad management. What do you mean, you have to work over 40 hours a week to change the world ? What kind of sad, dot.bomb era mentality is that ? The only way you'll change the world is by helping to make the stupid number of hours worked per week go down in history for the turn of the millenium period.
"The owner that you're all deriding, its HIS money on the line. He's paying you. "
Yes, but he's now offering the same money but demanding the employees work twice as many hours, which is just plain sick, even if he isn't increasing his own hours in the same ratio.
"If you fail, he loses money. You get unemployment and another job in a few weeks. You don't know what the owner has on the line. "
I think you overestimate the job market in the majority of places. Programmers have as much to lose as managers. If they lose their job they can't pay the mortgage, support their family etc, and getting a new job is very difficult at this time.
You seem to think that programmers are a "human resource". Well wise up, they're real people. You can't just push people to breaking point so you can retire at 40.
If this post has annoyed you- buster, you should have seen the other one.
graspee