News.com have an article on their site today stating that software developers are starting to work shorter, more normal work weeks (40 hours a week), instead of the 50 – 80 or even more that was not uncommon in the late 90s, early 2000s.
This is a great trend, not because I don’t love developing software, because I do, but I have plenty of other things I would rather be doing outside of work, like spending time at home with my wife and pets, and on my hobbies. After all, the main motivation to work for the majority of people is probably a) to pay the bills, and b) to earn money to spend on having a good time, whatever that may be – travelling, hobbies, eating out, going to movies etc.
The problem is, if you spend 12 hours in work every day, where is the free time to spend on the activities outside of work that you enjoy doing? And if you are working to earn money to enable you to participate in activities that you enjoy doing outsie of work, then when do you have any free time to take part in these activities? In extreme circumstances you might as well not be working at all because you end up with zero free time.
Software development is not a production line, or some machine that produces lines of code. If you can produce 40 lines of well written tested, working code in an 8 hour day, increasing the working hours to 16 hours a day is not going to get you 80 lines of code from each developer – software development just does not work like that. Software development is a cerebral exercise, one that takes a lot of thought, experiment, and dare I say it, creativity. Spending more time in one day on a task is not going to result in the task being completed sooner. Why? Because people get tired. On average, the average human attention span is something like 20 minutes – after that point the mind starts to wander, people need to take frequent breaks, tea/coffee/smoking breaks, and then start again on the task feeling more focused.
This is a point that project management and some project leadership just do not understand, and I cannot understand why, since most software development management were themselves programmers at some point.
The classic example that has happened to almost all of us I am sure is the late night debugging on a problem that you just can’t work out. Eventually you call it a night after having spent several hours on the one task. The next morning you come in, look at the code, and instantly find the problem in the code. Why? Because after working 10 hours plus you are tired, you are not focused, you are probably restless from sitting still for such a long time, you’re late for getting home for dinner, and there’s countless other chores nagging in the back of your head that you know you need to get home to do – in essence you are not focused on the problem. You go home have a good rest, and now the next morning the problem seems obvious. It’s not that it is now obvious, it just that you are now addressing the problem when you are at your freshest and most focused.
One of the other side-effects of working longer hours is when people get tired they tend to make more mistakes, or make judgements or decisions that they wouldn’t normally make if they were more alert and focused. So what happens after a late nate programming session? You come in the next morning and the first thing you do is you spend a couple of hours fixing the bugs from the previous night, or even reworking the code because what you wrote when you were tired is not the most effective solution to the problem.
So from spending an extra 4 hours at the end of the day writing some poorly written code and introducing a few bugs her and there, you waste a few hours the next morning correcting the mess from the previous night. This does not sound like an effective use of time to me. Over the longer term if your team is continually working long hours for 2 weeks or more, the problems become more severe – your team becomes demoralized and just generally worn out – people are not machines – to work effectively people need time to recouperate and rest in order to work effectively.
One of the rules of Extreme Programming is that no-one shall work more than 40 hours a week. This is not a dream – it’s realistic. If you demand more from your staff you often end up with less.
In software development overtime is never the solution to a problem – overtime is always symptom of a wider problem that needs to be addressed. If you don’t look for the wider problem, identify and address the issue, then the root cause of why you find yourself in the situation of having to ask you team to work overtime will not go away by itself – you’ll find yourself instead demanding more and more from your team which inevitably will result in lowering the morale of your team. Prolonged periods of overtime (ie more than 1 week in a row) will always have a far greater negative effect on the team and on productivity as a whole, than any short term positive gains.