Unfettered Blather

Hat Tip to The Press Pass for the lawsuit information.

I was not surprised to hear that EA ended up in a massive lawsuit over how they’ve been treating their employees. I find the whole thing a little odd since I am exempt from overtime due to being on salary, but I also don’t work in California either.

However, the lawsuit doesn’t address the real problem, which is that EA’s software development process is horribly broken. I am starting to understand why they are so devoid of inspiration or creativity when I hear about the conditions their employees work under. A software developer working 90 hours a week is not going to churn out a high quality product.

Extreme programming states that programmers should only work 40 hours a week. The justification is that tired programmers make more mistakes, and that at a certain point they are writing more bugs than useful code. I certainly support this theory and have seen evidence of it time and again. Unlike extreme programming fanatics, I do not believe in a strict adherence to the 40 hour week rule, as sometimes you need to do what it takes to get done. Still, with that rule in mind I try to monitor the quality of my own output. I have noticed that after about 14 hours of straight work my useful output drops significantly. Even as cognizant as I was of a tendency to make mistakes while tired, I still came in the next morning and had to rewrite a bunch of stuff.

The simple fact is that if your team is routinely breaking the 40 hour mark, something is wrong with the project. If this is a regular business practice for you, then your development model is broken. If your claim is “We must work [X] hours in order to make our 18 month development cycle” then you’re not getting it. If you can’t make an 18 month development cycle on 40 hours a week, it is because your project planning is horrible. Your milestones are likely unrealistic, you have a bad division of labor, and you believe that throwing time and “resources” (ie: people) at a project will solve it. How much of that 18 month development cycle is spent fixing the bugs the team made the night before? How much time is spent testing and rewriting buggy code? Is there a reasonable number of bugs? Or is each release so riddled with problems that you have entire releases dedicated to fixing problems?

I am watching the software industry trying to define itself, trying to put in place realistic processes that not only improve quality but also makes developers happier. Better morale and well rested developers are more productive. Working more hours does not mean more productivity. Software developers essentially think for a living. This is not an assembly line where you can just bang out a thousand pieces while on autopilot. It requires focus and concentration on the task at hand. If your developers are too tired to think, the answer is not to make them work more hours.

So you have a week where everyone works 70 hours? No big deal! They work 70 hours a week for three months straight? Now that indicates you have a bigger problem. The problem is not the software developers, but the people who set their requirements and expectations.

You can follow any responses to this entry through the RSS 2.0 feed. Both comments and pings are currently closed.