Software projects are notorious for getting into schedule trouble. And with that trouble comes more trouble.
More often than not, overtime is seen as a way of getting a project back on track and appeasing the “higher ups” that the project team is committed to its work and that they are doing everything possible to get the project across the finish line. Adding insult to injury – and in response to other demands – there are also people who are routinely asked to multi-task, finding themselves being switched between projects or problems on a moment’s notice.
Compounding the problem is that the use of vacation time – and even taking breaks during the day – has become counter-cultural in many organizations, particularly in America. We’re working longer hours and getting by on less rest than ever before.
The problem is that while overtime, multitasking, and a lack of breaks and rest may provide a demonstration of commitment and the desire to be productive, the truth is that all of these things do more harm than good when it comes to achieving actual productivity on software projects.
Why Overtime is Bad
One major issue associated directly with overtime is the effect on quality. In a paper, Impact of Overtime and Stress on Software Quality by Balaji Akula & James Cusick, Baleji and James studied the impact of quality when project teams worked on an aggressive schedule, examining four projects over a two-year period (three of which had an aggressive schedule).
A chart from this study demonstrates a dramatic difference in defect rates when no overtime is involved:
Estimated person hours
Overtime person hours
From my own experience as a software developer and as a software development manager, I’m certain about why defect rates are significantly lower with no overtime. Overtime means that there is schedule pressure, and the focus shifts to the output of features delivered at the expense of well-designed code and practices that are essential to quality.
What call would you make in this situation?
You’re working on Project X, and Project X is significantly behind schedule. Senior management has decreed that, “This is a critical project! All vacation time is cancelled until we get this product out the door!” The date is early November, and it’s beginning to look like you won’t be spending any time off with your family at Thanksgiving or Christmas, based on current projections.
You’ve just spent the last fifteen hours working on a feature and you are faced with a choice: refactor the code to maintain a solid design (because while it works, you know that the code isn’t as clean as it should be) or call it good, check it in now and move on to the next feature tomorrow. And your wife forcefully asked you yesterday – a Saturday – to pry your fingers off of the keyboard to attend your daughter’s soccer game. (This single scenario is actually a combination of two true situations taken from my own experience, bundled together to make a somewhat exaggerated point.)
What is your call? Check in the code or refactor it?
Craftsmanship and sound development practices will take a back seat almost every time, unless the development team revolts and pushes back because they understand the inevitable repercussions of taking short cuts. Unfortunately, there usually isn’t the right dialog between management and development teams in these situations, and often times a team will – silently – reduce their craftsmanship and create a worse problem.
For example, a team under significant schedule pressure and facing continual trade-offs between their job and their family will start cutting corners. It’s human nature. They may not be as diligent about technical reviews – a practice proven to be highly effective at reducing defects. They may even start skipping technical reviews completely. Other shortcuts might be taken, like not refining the code before checking it in.
Software development is similar to writing; your first draft may have captured the main points, but the expression needs to be refined. Without this refinement, poor design creeps in and the software becomes incrementally harder to add features to. The software becomes frustrating to work on because every change breaks two or three other parts of the code. These days this is referred to as technical debt. If the debt continues to grow, updates require increasingly more time and effort to implement, eventually forcing schedules to slip even more.
Demanding overtime is not a solution to a software schedule problem. A week or two of overtime can help to get past a hurdle, but continued reliance on overtime will lead to even greater problems downstream. It is better to get a grasp on the real issues of what is causing a schedule slippage and address those problems.
Why Multitasking is Bad
Computers are much better at multi-tasking than humans are. When a computer switches from performing one task to another, it saves the entire state of the task being switched out. This enables the computer to literally pick up where it left of when it returns to that task.
Humans aren’t wired that way.
Consider an activity that requires keeping a lot of details in your head along with applying some creative thought; where mental focus and concentration is essential, like programming. Developers keep a lot in their heads during the act of programming; how the code will be organized, what data structures are being used, the naming and use of variables, all of which is centered on the act of translating business requirements into detailed instructions for the computer to follow.
What happens when a developer is pulled off one task to work on some other issue? Valuable productivity is lost because it takes time for a human to return to the previous mental state when he or she returns to that task. This isn’t an instantaneous event like it is with a computer.
Consider the following graphic from the book Quality Software Management: Systems Thinking, by Gerald Weinberg:
The graphic illustrates how switching between only two projects is very costly: You lose twenty percent of your time! By the time you get to three or four simultaneous projects, you’re losing significant productivity to task-switching.
Another opinion is provided by James Shore and Shane Warden in their book The Art of Agile Development. They note that a programming task estimated at eight hours could take up to two to three calendar days if a programmer gets interrupted.
Just how much productivity is actually lost is a function of the type of work being performed. We humans are much more effective at multi-tasking with simple activities, like scheduling meetings, ordering lunch and responding to simple questions.
However, even something simple like e-mail has its dangers! Is there an expectation of immediate responsiveness in your organization? If so, this can be counterproductive because everyone feels compelled to react now, creating a situation of “continuous partial attention” that constrains productivity.
How does this understanding translate to my day-to-day software management universe? I have my own personal rule that I manage by: If something is important enough to start, it is important enough to finish. If I have to pull someone off a project to deal with a pressing issue (and I make sure that it is something that truly can’t wait), I try to find a good break-point for that person so that the impact of the interruption is minimized.
Ideally, I like to place control of any “interrupt” in the hands of others. If I really need an immediate answer on something, I’ll pick up the phone or walk over to their office and have a conversation. I don’t expect immediate responses to my e-mails – responses can wait until whomever I’ve sent the e-mail reaches a good point in their workday to respond without impacting their work.
Why a Lack of Breaks and Rest is Bad
This should be self-explanatory, but in practice too many people (particularly in American culture) suffer from the belief that rest is for slackers. This notion was captured nicely by Gordon Gecko in the first Wall Street movie, when he said, “Lunch is for wimps!”
In too many companies, there is an unspoken expectation to arrive early and work late – and take as few breaks as possible while you’re there. This starts us down a path to reduced mental sharpness because we aren’t pausing to refresh ourselves. And as we get fatigued we increase our use of stimulants like caffeine and sugar to “keep ourselves going.” This increases the stress levels and inhibits our ability to be truly productive.
Tony Schwartz , in his book, The Way We’re Working Isn’t Working, has a lot of advice to offer. For a start, Tony suggests that breaks are good. Tony notes that highly productive people tend to work in ninety minute sprints, focusing without distraction. These “sprints” should be followed by real breaks so that people can truly renew themselves.
Tony also notes that rest includes using vacation time, another increasing problem with American culture. Consider this: A 2006 study of employees at Ernst & Young, the accounting firm, found that for each ten hours of vacation employees took each month, their performance reviews were eight percent higher the following year.
Finally, Tony has this advice for managers:
“As a manager, creating a new way of working begins with recognizing that renewal serves performance. Stop evaluating performance by the number of hours employees put in and instead measure it by the value they produce. The second shift in a leader mind-set is from a singular focus on the competency of employees – the skills they need to get their jobs done – to an equal emphasis on capacity – the quantity and quality of fuel in their tanks.“