There are two types of overtime. I call them forced and unforced. Some call them involuntary and voluntary, or required and elective. No matter what you call them, overtime as a policy in a software development company is not a good sign. In general, I don’t work either kind of overtime.
First the definitions. Forced overtime is the overtime you are required to work. It usually follows a “request” from management which is subtlely or not so subtlely accompanied with threats of penalties if the request is ignored. The request is also often accompanied by promises of the situation being short-term and the company making it up to the developers as some later date. Both these promises are suspect at best.
Unforced overtime is rare, but it does exist. This is the overtime people actually want to work for some reason. The reason can be misplaced loyalty, guilt, or in very rare cases, actual enjoyment of work. Whatever the reason, the company usually sees this as a good thing since the people “volunteer” and the company doesn’t have to pay extra. The line between forced and unforced can be fuzzy at times. Companies may request that developers “volunteer” for overtime, leading to pressures both overt and covert from management and peers to work the extra hours.
Now my opinion. Overtime in software development is bad. It is an evil sign that management doesn’t know what is going on and the project or products being developed aren’t being managed properly. It allows management to take advantage of their developers. It is abusive, at best. Now my corollary. Life, as a rule, is unpredictable. Even the best of managers can’t foresee everything that is going to happen. So the occasional need for a few extra hours work is generally acceptable. What I’m talking about here is the chronic use of overtime as a means to develop software.
Whether the overtime worked is voluntary or not, people can only work a certain number of effective hours per week. The problem is that people get tired, both physically and mentally. Sure, some people can stay awake and focused for longer times (especially with the aid of legal beverage delivered drugs), but eventually people get tired. And when people get tired, they start to lose focus and make mistakes. If you want warm-bodies sitting in a seat pounding out crap code, that is one thing, but if you want effective developers building quality code, then overtime is not the way to go.
I have never worked very much overtime. In addition to that, the successful software projects I’ve been involved with did not require an inordinate amount of overtime for me or my co-workers – at least not that I recall, and if I don’t recall it then whatever amount of overtime there was, obviously wasn’t deleterious to my well being. In all cases, the determining factors for this lack of overtime were quality management and quality code. Quality management means realisitic schedules developed with input from the developers. It means management trusting the opinions and judgement of the developers and openly communicating the state of the project with everyone. It means actually actively managing the project rather than setting out some milestones, hitting the go button and waiting to see what pops out the other end of the developer machine. Quality code requires focusing on quality at every level of the system, from component interfaces, to component internals, all the way down to the lines of code. Clear interface definitions, proper abstraction, proper encapsulation, simplicity, and consistancy are all signs of quality code. Things like design walk-throughs, code reviews (both at the computer and on paper), stable development environments that don’t get in the developers’ way and good old fashion relaxed and happy developers are all things that lead to quality code. Quality code also has a direct impact on developer productivity. If you want developer productivity to go up, then build quality code. Higher productivity means you can get more done in less time, which means you don’t need overtime.
If you need overtime to finish your projects then the likely problem is lack of quality in both management and code. Overtime is not the solution to crappy, late, over-budget projects. Solve the real problem and everyone will be much happier.