Impact of Overtime on Productivity

Discussions

News: Impact of Overtime on Productivity

  1. Impact of Overtime on Productivity (26 messages)

    From the very beginning, eXtreme Programming has been about instilling habits into the development process that should increase productivity. One of the ideas was the practice of sustainable pace. In this article entitled "Industrial Accidents and the Professional Programmer", Ron Jeffries looks at just how important pacing ones self really is. There are always pressures put upon us to work more then we should. But what are the effects of all of this over time on our work and life in general.
    Clearly there must be some upper limit to how many hours we should put in, but how can we figure out what that limit is?
    After some research on the subject, Ron was able to find evidence that bad things started to happen when people worked more than 8 hours per day or forty hours per week. In industrial jobs, rates of accidents increased disproportionately. In a study of medical interns who are expected to work 24 hour shifts, it was discovered that they were twice as likely to have an auto accident. Though the study hints at it, it says nothing about an intern’s ability to make sound medical judgments after working these many hours. And how does all of this apply to developers.
    My educated guess would be that the insertion rate for defects increases far more rapidly than the risk of industrial accidents. What the accident statistics probably tell us is that a tired programmer has double the chances of putting in a very serious bug, but has probably also put in a much higher percentage of smaller ones
    The article then dives in the disruptive impacts that defects have on the development process. These impacts include the unpredictability of the process of removing them (commonly known as debugging). There is much more in the article that suggests that working longer hours is not a great idea. How often do you work longer then 40 hours per week and how do you feel that this affects your productivity?

    Threaded Messages (26)

  2. This basically an emphasized +1 ;-). As Jeffries states:
    Programming is a work of the mind
    I think mindworkers like we are cannot really be focused and productive for more than about 6 hours a day. The rest of the working hours are spent chatting at the coffee machine and checking the mail. At the end of a (sometimes-not-so-successfull) working day I always try to reach a "cliffhanger" from where to depart the next day. Most of the time the problems that seemed totally unsolvable the previous day at five are fixed in a mere couple of minutes after a relaxed evening and a good night's sleep. I really think in the long run the nine-to-five programmer is actually the most productive one.
  3. Good developers have a "go switch", a second gear, that they can go to. Afterburners. Finals crunch time. Whatever you want to call it. But I would say the most this can be practically used is two weeks, and then there is a crash. At least a week is lost per two weeks of go time. And the only people that can inspire this are good managers who know when to use it. If managers try to push go time past the breaking point, all will go well for the first week or two, and then productivity will drop regardless of the number of hours attended by your workers.
  4. Good developers have a "go switch", a second gear, that they can go to. Afterburners.
    Using afternburners (aka reheat to our European listeners) on a jet consumes fuel at a ridiculous rate. For example, Concorde's empty weight was 173,500 lbs. or 78,700 kg. It's fuel load was 210,940 lbs or 95,680 kg. It had to carry more than its own weight in fuel in order to sustain supersonic speed because it required the engines to run in afterburner. The same applies to developers. They can't sustain 'afterburner' mode for very long and remain productive. Dave Rooney Mayford Technologies
  5. +1 for me as well. I fully agree that the negative consequences of overtime have generally been ignored in our industry. In fact, I've written an article about this problem called Overtime Considered Harmful (http://www.basilv.com/psd/blog/2006/overtime-considered-harmful)
  6. My 2 cents[ Go to top ]

    Here is what I have seen in random order: * When you ask people to work 60 hours a week, they "show up" for 60 hours a week and work about 40. The other 20 is spent paying bills online, complaining about the long hours, drinking coffee, falling asleep at their desks, etc. * Most people I have worked with can do 2 weeks of long hours and get more done. This works ok if you absolutely need to get a project out that a tiny bit behind. After that the "wasted time" scenario above happens. * After working too long you have to take a few days off (not on the weekend) to get back to full productivity. * If business is poor and I will have a hard time finding a new job, I am more likely to get things done when working too much. * I can personally do about 42 to 46 hours a week indefinitely. At that rate, I can get things done. Beyond that, my productivity goes away. If things are busy at home 42 is the number. If things are placid at home, 46 is ok. * Asking people to do 40 hours of programming a week and then read their email and read a few newsletters or blogs and go to non-project related meetings is a long-term disaster just waiting to happen. In our business, we have to have time to keep up with the industy scuttlebutt and read up on technology's movement. If we don't, we become more and more useless as time goes by.
  7. couldn't agree more! i had a job in london, working for an american cto who believed the developers should get to work at 12pm and work until 12am, drinking coke and eating pizza all day because thats how he remembered working at university! He had a pop at me on my first day after working 8-5, again on the second day and by the start of the second week he gave the PM a talking-to for *letting* me leave so early! Off I went at 5, jumped on my bike and cycled home. Meanwhile, some of the other developers would stay until after 11 o'clock, eating pizza and ... The funny thing was, our CI invariably flagged up problems with the build after 9 in the evening, seeing as the guys only started at 11-12, 9 works out as the end of a longish day. Next morning, I'd arrive in early, have a shower and sit down to work, and have a read of the build problems that had arisen the night before! Often I'd have to wait for the developer to get in to fix the issue depending on the part of the application he was working on. In one situation, a guy worked until 4 in the morning, so he didn't come in until 4 in the afternoon the following day! He made up an extra man-day with the extra hours, but cost about six man-days because we couldn't progress until he fixed the problems he had caused. There are two important reasons for not working late; firstly, beyond 8-9hrs of sitting in front of a screen, it would me more productive to take a long break than to push it, and secondly, business people work 9-5, if the developers don't behave like part of the development team then business people start thinking about outsourcing/off-shoring when they see that the business and technical don't *need* to work hand-in-hand.
  8. if the developers don't behave like part of the development team
    doh, meant to say "part of the business or project team". Time for me to go home, even though I;ve just sat down :$
  9. Overtime is not only about productivity, for example, if you work 12 hours per day, at end your will left that job, and replace an developer is an really high cost (an good programmer is not productive in a new job until 6 month, at least) other example, if all programmers does not do overtime at the same level, in long(or not so long) term frictions between fellows will arise, and then the possibility of creating jelly team is lose. Even in the case that overtime increases the productivity, overtime still is an expensive practice for any Development Company Cheers
  10. an good programmer is not productive in a new job until 6 month, at least
    That's not true. The new good developer can be productive the first day if it is assigned to new module or design review instead of fixing bug on complicated legacy code.
  11. I agree with this to a certain extent. But I think there are many factors that affect what this limit is. For some individuals it might be as low as 5 or 6 hours a day on average, and for some 9 or 10. But even then it's just an average! On a well rested day working on an interesting problem in an interesting domain I can happily go a couple of hours longer than usual. Of course, there's still a drop off point - but maybe that day I hit it a couple of hours later. So I don't think there is any magic number like 8 hours a day or 40 hours a week. Maybe that's the average, but it's affected by things like: - how well rested you are on a given day - how interesting the work is - the work environment itself - the amount of pressure to finish So from a management perspective pushing people to work long hours in a crunch period to get things done is probably horribly counter-productive. But trying to impose a specific limit would be too. I'd hope most developers are intelligent enough to know when they've had it for the day and go home. -Tim Fennell Stripes: Because web development should just be easier
  12. you're right, it depends on the developer. my old "cto" thought it best that the whole team stayed at worked together to "build team spirit", but a developer knows when they can achieve something and when they are just punching-in hours. I read an article before about a guy who worked when he felt like it, e.g. if its raining outside then he'd stay at work longer and get some more stuff done, but if the next afternoon as sunny, he'd take off knowing that it would be a waste trying to write code when his head wasn't in it. That could work when you trust your employees, but we had something similar ("working from home" :) ) and it was so badly abused by one guy that they revoked the privilege from everyone in the group.
  13. Wow, the posters on TSS must be getting older. If you had have asked me 8 years ago what good development practices were, I'd have said [12-12]+pizza+coke=hyper-productive, but as I have worked my way from developer on up I think a different realization has come to me. I personally see programming as an art not a science. You don't do your most impactful art on a regular 9-5 schedule without some serious discipline and control. I'd wager that most of us have momements of pur inspiration, moments where we completely loose the muse, or long stretches of creative drought. In that light, I prefer the statement about letting developers work out what and when they need to be productive. The challenge in that is that to truly have faith in your team to do that, you need to be able to LEAD them not MANAGE them. Your team needs to be committed to the business problem, they need to understand their place in the cosmic game of users, clients, requirements, tests, and code and they need to be willing and able to focus their creative energy on the task at hand.
  14. Making money out of art[ Go to top ]

    Well Dean, if you want to hire some new developers I think you just have to post the company you work for and let the CVs come to you ;) Seriously though, I think that most GOOD programmers are like artists and about 95% of what passes for programmers here in Europe are not *that* good and in fact something like 70% of them didn't even get trained in computer science. As for artists, even artists have to eat and the question is how to get good productivity from them? The answer I think is that you don't have to because if they're that good they work in R&D and not on a time schedule. So where exactly do you work Dean?
  15. shameless plug for the company I work for ... Sapient www.sapient.com
  16. The challenge in that is that to truly have faith in your team to do that, you need to be able to LEAD them not MANAGE them.
    Great!!! Guido
  17. Think Longer Term[ Go to top ]

    I agree with this to a certain extent. But I think there are many factors that affect what this limit is. For some individuals it might be as low as 5 or 6 hours a day on average, and for some 9 or 10.
    The key here isn't to think in terms of a few days or a couple of weeks, but over 3-6 months or even a year or two. No one is capable of sustaining 12-hour days producing quality code for anything but small increments of time.
    On a well rested day working on an interesting problem in an interesting domain I can happily go a couple of hours longer than usual. Of course, there's still a drop off point - but maybe that day I hit it a couple of hours later.
    Absolutely!! The clue in that last quote though is the term "well rested day". Bearing in mind that developing code is a mental exercise much more than physical, how do you get that rest? By not working long days very often!
    So I don't think there is any magic number like 8 hours a day or 40 hours a week.
    Yup, and that's why Kent Beck changed the XP Practice of 40-hour Week to Sustainable Pace. Different people on different teams in different circumstances can sustain different paces. Dave Rooney Mayford Technologies
  18. Whatever studies show and practitioners know in heart, in reality many bosses and managers still require you to work overtime. Many even state that in a job requirement or as an interview question! Business world pay lip services that staffs are the most important asset of the company, and that work smarter not harder, to name a few. In practice many developers need to work harder and longer. You sell both of your white hair and your brain. On top of that, at the same time you may need to worry about one day your company will outsource the stuff **[Editors Note: content removed due to it's offensive nature]** (the best scenario is that the upper level forces you to be another ** **[Editors Note: content removed due to it's offensive nature]** manager). >_< Message was edited by: kirk@javaperformancetuning.com
  19. yes, anyone that works over 40 hrs a week on a regular basis is not doing themselves or their company any favours. In an interview I had a couple of years ago the project manager stressed how 'mad' things sometimes got and people were required to work hard/long hours. He asked me if that would be a problem. I replied yes it would (detailing why i thought long hours were counter-productive) and got the job anyway.
  20. ugly China or dirty India?[ Go to top ]

    Bruce, What's **[Editors Note: content removed due to it's offensive nature]**? Are you a professional? Or you are afraid of loosing you job because you are not competent enough? Mind your words please, because TSS is international. Regards
    Whatever studies show and practitioners know in heart, in reality many bosses and managers still require you to work overtime. Many even state that in a job requirement or as an interview question!

    Business world pay lip services that staffs are the most important asset of the company, and that work smarter not harder, to name a few.

    In practice many developers need to work harder and longer. You sell both of your white hair and your brain. On top of that, at the same time you may need to worry about one day your company will outsource the stuff to the **[Editors Note: content removed due to it's offensive nature]** (the best scenario is that the upper level forces you to be another **[Editors Note: content removed due to it's offensive nature]** manager). >_<</blockquote> Message was edited by: kirk@javaperformancetuning.com
  21. The problem is I'm not sure those exist anymore. Yeah, sure, most of us are officially "salaried workers," but that's just a way for employers (at least in the US) to avoid all the extra regulation that's associated with hourly paid workers. But if we don't have at least 40 hrs a week of "productive" time charged to a project, we're in trouble. That means things like staff meetings are uncompensated overtime. Personally, some days I can work a hyper-productive 18 hours and some I can't manage to accomplish anything. If we were really treated as professionals, we'd be measured by how much we accomplish, not how many hours we spend working at it. But I don't know anyone in any profession that is treated that way. You spend at least 40 hours per week working, and most of the time there should be at least 8 hours in every weekday. If we spend one day zoned out or waiting for someone, we're supposed to sit and pretend to be working (or post on TSS ;-), then work two 12 hour days to make up for the lost productivity. When in reality we could have spent one day at home and then worked two twelve hour days and been just as productive and a lot happier.
  22. There's a measurement problem here. In factories, overtime only has a slight correlation with pressure to produce. An employee might work overtime to cover for a vacationing co-worker or just because he requested it. So, a study correlating accidents with hours worked has merit. However, in software development, project overtime (as opposed to "bad production problem" overtime) almost always results from a team getting behind rather than being driven to get ahead. Developers are likely to both work longer hours AND take shortcuts to get something out the door. So, if one measures the bug count per coder per week and correlates it to hours worked, he will likely see a strong relationship. However, it is difficult to differentiate the effects of overtime from those of increased schedule pressure. An accurate analysis almost requires a controlled study -- some developers work normal hours and others work three twelve hour days per week under the same project estimates. I know that I become less productive as the day progresses, so I don't doubt that longer hours alone contribute to bugs. But, I don't think that most study methodologies relying on real world data are valid.
  23. I think working 40 hours is nice if you can do the thing you hired for. If you are doing things aside, like checking personal email and other private stuff, then it's not nice to say that you work 40 hours a week. Okay, you get paid for 40 hours, but effectivly make less productieve hours. I know there are some guys who work moere that 50 and do it with all the love of their jobs. They are happy with it. I also know guys that live by "less is more". If a amanager is happy and only focused on results, then someone who can get the job done, while fooling around, is quickly accepted. So if you're great, then it's okay. Nice to know is that I'm a technical teamleader and my guys work different shifts, and have different working mentality. I just handle them, the way they handle their jobs. If they do it with respect, then they receive respect.
  24. personal life[ Go to top ]

    It is funny nobody mentioned kids and wifes/husbands ... Do you have some kids??? How can IT guys reproduce their great genes??? If you do not spend enough time with your family it is not going to work. Your kids need some parenting and your wife needs to talk to somebody ... After 8 years in IT industry my family is on the first place and job/managers/HR is just a necessary evil to pay my bills. It is difficult to find an interesting project in an Enterprise area. DBs, app servers, integration, portals ... I just do not see it interesting anymore. It is not bad, it is not just funny. If I do not need to make money for living I would do some neural network research, from home ... :) Anyway if overtime is going to harm your personal life (what is quite probable), then your productivity is going to be killed for a long time. If you management wants to keep you for 5-10 years in the company, then they should be very careful about that. IMO the overtime is always a management fault, nobody's else. So improve the management ....
  25. If you want to be successful as a IT professional / consultant, IMHO you shouldn't marry and/or have kids. There is hardly enough time for work, overwork, personal projects and keeping up to date with stuff. And No, I am not joking !
  26. If you want to be successful as a IT professional / consultant, IMHO you shouldn't marry and/or have kids. There is hardly enough time for work, overwork, personal projects and keeping up to date with stuff.

    And No, I am not joking !
    ...or marry a trial attorney...then you don't feel so bad.
  27. It is not how long ... but how good which when an artist is swimming in their creation has no time boundaries. The cosmos of computing are tied up between neurons in those developers heads like layers .... of an Onion. No ... not Shrek ... or Ogers but layers built by the Developer as an abstraction of their design. In the mind first .... and over time drawn out on a canvas in a pseudo machine language which captures those thoughts and constructs a repeatable process in a form that someone else might read them and understand them. These thoughts carry over for good developers long after and before they are there ... or not there .... OverTime ... sheesh .... a management term ... not a developers term. Normally associated with chaos .... or just plain spaghetti.