How prevalent is overtime in software development?
According to Stackoverflow’s 2020 developer survey, a quarter of the respondents said they work overtime on a weekly basis, while another quarter of them reported working overtime a few times a month, and other respondents reported overtime less frequently.
The recent spotlight on overtime in game development (also referred to as “crunch”) suggests a greater prevalence of overtime in this specific industry, however, according to the survey, game developers reported a 41-hour workweek on average, and less than 13% of all developers claimed to work more than 50 hours a week.
Other surveys focusing specifically on game developers had reported higher numbers, with nearly half of the developers saying they work more than 45 hours a week. But in the 2019 International Game Developers Association survey, this was only true for a quarter of the respondents, which may not be unrelated to the media coverage surrounding the issue.
These numbers don’t suggest excessive overtime. Is it possible that the myth of developers working overtime is really just a myth, and despite the media attention, it only affects a smaller part of the sector?
Is there a difference between overtime and overtime?
Should we work overtime or not? The answer is not necessarily clear. Of course, there are aspects to consider when it comes to the approval of overtime, such as whether we get paid for overtime at all, if we do, are we getting paid enough, how frequently we have to work overtime, and how many extra hours are we required to put in.
But the complete rejection of overtime is a valid standpoint as well. Moreover, there are trends in agile development, such as extreme programming (XP) that rejects overtime (in theory anyway), because overtime is perceived to be the consequence of low efficiency, poor estimation, poor scheduling and poor organization.
This leads us straight to the next issue.
What generates overtime?
Some aspects of software development may lead to generating overtime, such as:
- poor estimation and scheduling
- poor communication with the customer (e.g., frequently changing requirements / specifications) and / or between development and management teams
- poor assessment of customer needs and over-promising
- inadequate professional training of developers (too much time spent on learning / teaching the chosen technologies or suboptimal senior/junior ratio in the team)
- understaffing: too few people are tasked with too much work
- progress is hindered by constantly having to fix technical debt
- perfectionism and too much experimenting
This could mean that improving certain aspects of development, management and cooperation might make overtime unnecessary or at the very least may reduce its frequency.
Others emphasize that proper planning and design will ultimately lead to a cheaper and better quality product, without the need for overtime work.
What are the consequences of overtime?
Examining the relationship between overtime and performance, we could easily conclude that overtime and its side-effects lead to a decrease in the quality of work and an increase in the number of errors.
Overtime can have a demoralizing effect on both the team and the individual, and the stress associated with it increases physical and mental health risks, not to mention its negative impact on our social life and relationships. This can inevitably lead to burnout which is reported to be paricularly high among IT professionals, because the frequent changes many of us are facing can be hard to deal with, especially if it becomes a constant sense of urgency.
But does overtime have positive effects? A common excuse for overtime is “making up for lost time” and “keeping deadlines”, so there is an implicit assumption that our project can benefit from this practice.
What can we truly accomplish with overtime?
There is a chance that you manage to finish something last minute, with a bit of extra time put in, but this usually happens when the overtime is not excessive and the negative effects of the above mentioned demoralization, and lowered performance attributed to the lack of sleep and increased stress does not manifest yet.
Another positive aspect of paid overtime could be the extra income, and taking up the occasional overtime work might be desired when it comes to a promotion or a pay rise. Is it meaningful to work overtime?
Some may argue whether it’s even possible to spend 8 hours a day doing actual work in software development. Time spent at the workplace may not directly translate to time spent working, and it’s debatable whether it’s possible to maintain focus and efficiency for such a long time.
Just like in many other cases when we have positive bias towards ourselves, we tend to overestimate our productivity as well.
But if the efficiency of regular work is questionable, what about overtime work? The current discourse around overtime is leaning towards considering it a negative by-product of software development, or a necessary evil at best, and not an actual tool for problem solving.
Wrapping up
I don't think it's entirely possible to avoid overtime work, but after looking into its perception and its effect not only on work quality and efficiency but also the mental state of the individual, I believe we should take steps to try to avoid it. By avoiding it, I don't necessarily mean straight out refusing to do any overtime, but a more assertive approach could be to analyze the causes to learn from it and do better next time.
Improving our estimation, planning and team communication, avoiding over-promising and making sure the team has the required skills and competencies to deliver the desired feature are all tools in our hands to improve our own processes, and protect our team from burnout.