Crunch Times

With a deadline fast approaching, it’s really simple to make sure your team finishes, all they have to do is work more! Well… theories and studies from over 100 years ago easily show there is an efficient amount of time someone works. Do a quick Google search for “does crunch mode work” and you’ll inevitably end up with a reverberating “NO!”

One of the big problems about quantifying crunch time is that there is not an efficient way to measure programmer output. Since there is not a good metric, there is no black and white line that says how much a programmer should work to maintain optimal output. The idea of a 40 hour work week is accredited to labor unions from as early as the 1860s. Henry Ford was an early proponent of the five-day work week. There has even been recent traction for companies to adopt 4 day work weeks as well. Studies show that working less is beneficial for an employee’s health, focus, productivity, morale and quality of life.

Even if there was a metric, programmers are very creative problem solvers. If the problem is as simple as “how do I make this number higher,” it’s something they quickly solve. I’ve seen this with developers who don’t like to make unit tests. In a previous company/team, we decided code must have at least 80% test coverage. The programmer ends up figuring out the limits of the tool that measures test coverage, and just learns to game the number. In other words, just make 80% of the code run while testing and you have “80% test coverage.”

From research and experience, it only takes two to four weeks of working 50 hours to reduce a programmer to the efficiency of only working 40 hours. In other words, in 100 hours of work, they are as effective as 80 hours. Keep it up, and the programmer gets burned out and quits; then you have no one to finish the product and you’ll never hit your deadline. I see this type of thing happen the most with the highest performing members of the team. Therefore, teams tend to lose the best developers.

I can speak the most about my own personal experience with burn out from crunch times. I have worked at a multitude of companies that apparently believe a person can work 60 hours a week and be fine. I assure you, this is not true. Recently, a developer on another team decided to go out of state for a holiday to visit his family. I was asked to sub in for him on his project as they were trying to push a feature out the following week. This developer happened to be working on his own and thus, no one was making sure his code was up to our standards. I joined the team’s Tuesday stand-up. The developer was to finish code and push a build out for QA to test, and I would take over Wednesday morning. The developer then went on his trip. I came into work the next day bombarded with 14 defects from the code that had been written.

Of course, this was a feature under a huge deadline, so it was now on my shoulders to turn it around. I worked 40 hours over the next 4 days, two of which were holidays, to just fix all of the bugs and bring the code up to standards. So I pulled a 56 hour work week, and then had a Sunday off. By the time I came in Monday morning, I was still exhausted from the previous week, and my productivity was extremely low. Based on the experience the previous week, I actually decided to quit and gave notice that week. This wasn’t the first time developers at the company were held under the gun, and it made me realize it wouldn’t be the last. I realized I wasn’t growing by just reimplementing other people’s code until it actually worked. It was time for me to move on.

Unfortunately, the job cycle of a developer these days tends to be something like this:

• Work really hard
• Realize this place is not a fit
• Give notice and quit
• Maybe take some time off
• Find a new place
• GOTO 1

This is something the industry has created. Instead of growing developers, companies are utilizing them as resources rather than assets. Using them as much as possible, burning them out, until they leave because they get the promise of greener pastures elsewhere. However, I will let you in on a little secret, if you a position is great, the developer would never ever want to (or even consider) leaving.