Roy Tang

Programmer, engineer, scientist, critic, gamer, dreamer, and kid-at-heart.

Blog Notes Photos Links Archives About

Overtime

Overtime in software development projects seems to be a given. Sure, there are projects and companies that don’t need it, but those feel like the exception rather than the norm

Overtime in software development is a natural consequence of schedule pressure and the fact that estimation is hard, which is why it’s understandably common, but that doesn’t mean we shouldn’t try to avoid it

More than once I’ve been in a situation where the team stays overnight to try to get a build or release ready for the next day only to run out of time and have to delay the deployment anyway. You have to be willing to cut your losses and quit early, and just come back and finish the work the next day, when your productivity isn’t shot by tiredness and the general crankiness of the long hours. When the whole team is still in the office at 3AM waiting for new builds, every delay or new defect is met with a drop of morale and increase in grumpiness, no matter how small

Staying too late quickly hits a point of diminishing returns too. For one thing, working too many hours leads to poor quality and sloppy work. Ted Mosby famously said “Nothing good ever happens after 2AM”, that’s mostly true for software development too. More than once I’ve gone to work the next day and saw how I screwed up something the night before. Mistakes made during toxic overtime affect the next build too, and the one after that, and those problems cascade into more overtime. They all compound in one vicious cycle. It’s better to just do the work in the morning when you have a clearer head to hopefully not continue the cycle

Those are just the productivity and quality downsides – there’s also the problem of high overtime levels leading to increased absenteeism, lower health levels, and higher turnover rates

The realities of business and schedules and deadlines don’t always let us avoid overtime, but hopefully every time we’re forced to do so, we learn from those instances and figure out how to plan better next time (or to get the client’s understanding to be more flexible with scope and schedule)

Posted by under post at #Software Development
Also on: tumblr twitter / 0 / 368 words

See Also