Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

There is some thinking going on around how to get more output from the current resources we have. The thought is that two teams working different shifts might produce more output. The first shift might work 8am - 5pm, and the second team works 4pm - 1am. There is an hour overlap for status meetings and any communication that needs to happen between the teams.

You would obviously need two team leaders, one for each shift.

So far, the benefits I can see from this are:

  • Better ability to respond to customer issues (time zone affects things less)
  • Utilize the same workstations, equipment, and office space (less cost per developer)
  • Allows "night owls" to work at night, when they're more productive
  • Might be able to complete certain less complex tasks in less days (not time, days)
  • Less people in the (open-plan) office, meaning less distractions and higher productivity

The drawbacks I see are:

  • Developers don't have a space or equipment to call their own (am I the only one that cares about this?)
  • Communication between the teams will suffer since they only see each other for an hour each day
  • Much more documentation and specification writing will be necessary (you can't rely on on-the-fly decisions from decision-makers because they might not be available)
  • Older developers tend to have families and night-time activities, and don't want to be at work

Any other thoughts? Has anyone worked in this type of environment? I'd be curious to hear your thoughts on this development model, and your opinion on whether it was a good one or a bad one.

share|improve this question
So when the night shift ends at the mine, there´s no meeting between the teams? The day team will work through without even knowing if the night team has made any critical decisions. Unless you make the night team go back at 8AM and hold a meeting....looks like a winner. –  Tom Nov 1 '11 at 18:58
@Tom No, you add a third team for the 12am-9am shift. Cycle complete. :) –  NickC Nov 1 '11 at 19:48
Food for thought: It has been shown that adding developers to a project that is late tends to make the project even more late. Once you understand the reasons behind that, you'll understand why your suggestion is completely counter-productive. –  Stargazer712 Nov 1 '11 at 20:23

9 Answers 9

Software development isn't a manufacturing type process where people are essentially interchangeable resources. It’s a creative process that works within the collaborate environment of a professional team that takes into account individual abilities and skills. It’s not making widgets, packing boxes or flipping burgers. In fact, these kinds of throwing more programmers at the problem tend to make solutions take longer. It's very difficult, if not impossible, for one programmer to work 8 hours then have another programmer start working where the first left off for another 8 hours.

Now, there are ways where a large enough project might get broken up where programmers work at different times or in different ways as long as they maintain the creativity and productivity of the team. Extreme Programming is one example. Another would be a team that's partially offshored. I worked a one company where one developer worked from his cabin out in the woods, only coming into the office once a month or so, and another worked from 11 PM to 7AM. There are plenty of flexible ideas to try but a pure manufacuturing approach isn't likely to work.

share|improve this answer
"It’s a creative process that works within the collaborate environment of a professional team that takes into account individual abilities and skills. It’s not making widgets, packing boxes or flipping burgers." +1 –  Wyatt Barnett Nov 2 '11 at 2:49
I think answer smartly summarizes essence. –  Manoj Nov 2 '11 at 4:35
This x1000. Amazes me how management and even other developers seem to think this is a manufacturing profession where things can be automated or streamlined like McDonalds. –  Wayne M Nov 2 '11 at 13:24

Having Development and QA on separate shifts that are mostly opposed works out pretty well in my experience. Say the Dev team is in the US and the QA team is in Romania.

This gives you a few hours of overlap in the morning EST for syncing up without overly burdening either side to be up extremely early or work extremely late.

This also lets you effectively "stack" two days into one. Since these are largely asynchronous tasks to begin with, works very well with an Agile Methodology such as SCRUM.

As the time differential drifts more towards 10+ hours this stops working as well. Say US EST vs IND time. Morning in India is 10PM - 12AM and morning in US is late in India. Someone is going to be un-happy with their schedule if you have to have real-time conversations to do your work.

That said, having one "shift" pick up where another left off in Development is a recipe for un-happy un-productive employees.

share|improve this answer

This is very subjective, but in accordance with guidelines I will try to answer from my own experience.

My experience

I have been required to work in an environment like this and although I am sure there are examples of successful shift working in software engineering, from my own experience it's, quite frankly, a nightmare.

In my case the resource under contention was a development laser scribing tool. Software guys were given the late shift (2pm start), while hardware guys were given earlies (5am start).

Every day we spent ages trying to work out what hardware modifications had been made over night and what effect these would have on our software. It meant running complex baseline tests every day or risk not knowing whether a problem was due to our software modifications or a hardware change. It also meant that when we had hardware problems that we couldn't sort out ourselves, there was no-one around to help.

I suspect that the hardware guys had similar problem adjusting to the shifting sands of our software too.

My suggestions

If you only have software to worry about, things might not be so bad. Teams from different time-zones collaborate with little physical overlap all the time.

Other things which might help could include a strongly TDD environment, and one which uses modern DVCS, like hg or git, and one which uses agile techniques.

Being able to quickly and easily run all of the unit tests, create a branch for fixing a bug, or adding a feature, keep commits local until you are ready to push back to your main-line etc. and having a large pool of small, well defined work units could all help control the complexity of such a working environment.

Other caveats

Finally, while people might say they are fine working this way, they may not stay fine with it, so you will have to keep a close check on peoples satisfaction levels.

I coped with several weeks of shift work during a crunch on the project, but I would have been ready to walk if it had been any longer, and I certainly wouldn't have been happy with this situation extending indefinitely. - Even night owls need to socialise with their friends at social hours.

share|improve this answer

I generally agree with jfrankcarr. On the whole, programmers aren't like manufacturing workers. You expect your programming staff to come up with creative solutions to problems; conversely, the last thing you want most shift workers to do is get creative with your product or business processes.

I will concede that if the limiting factor is technical equipment (for instance a tech lab to test out device drivers or communications routines on real hardware) then having that equipment be used for more hours of the day, instead of buying more equipment, can save you money in the short term. That's the main strategy behind shift work; the equipment can easily be shut down for the night, but if it isn't running it's not making you money. If your technical environment requires equipment that is insanely expensive and/or otherwise difficult to provide enough of to allow all the required use during daylight hours, then consider shift work.

However, it's not the computers, certainly not the workstations, making you the money. It's the user of that computer who is using his brain to solve problems for you and your customers. By our very nature, brains don't work as well at night. The computers are also a drop in the bucket; you pay the developer more in a month than it costs to buy their workstation when they start. Space can be a limiting factor, but again, it's usually not major unless you're at a real bare-bones cost structure to compete solely on price.

share|improve this answer
"more in a month?" In the US a workstation and a programmer-day have about the same cost. –  kevin cline Nov 1 '11 at 20:03
Depends on the workstation ($2500, about two to three weeks' gross salary for the average mid-level developer, buys a damn nice computer) and whether you consider ALL the costs (including healthcare, 401k matching, payroll taxes, etc). But yeah, the monthly operating cost of my Agile team of about a dozen people was roughly $300k/mo, meaning each programmer cost the company (and thus the clients) about $900 per day worked. You could get a computer worth programming on for that. –  KeithS Nov 1 '11 at 20:15

I once did a shift - we needed a final acceptance test using a real Airbus A320 to test some software changes, a friendly Airline had one available at 2AM....

If the cost of the hardware is a desk and a PC, I hate to think what they are paying you....

share|improve this answer

Sounds very odd to me. What if you're in the middle of coding something when the next shift rolls in? Do you just turn the coding over to someone else, or tell them "I'm working on this, don't change anything, I'll finish it tomorrow"? What if you're in the middle of a debugging session, do you dump the problem on the next shift, or keep working (and make someone else wait for the machine you're using)?

I guess it might be OK if your work can be broken down into lots of discrete units such that you can reasonably expect to complete an integral number per shift, or the two shifts can work on disparate parts of the project (but in that case it'd be faster to have them work in parallel). I really don't see an advantage that'll compensate for the increased communication overhead.

share|improve this answer
Really the only advantage I see is maximizing use and efficiency with limited workstations. –  maple_shaft Nov 1 '11 at 17:18

While it feels perverse and unnatural to me, it is still an intriguing idea. I personally am a morning bird so I would absolutely want to work during the day.

I guess it could work as long as evening shift was completely voluntary. Further I will add that each team should be working on different projects/components/software/etc...
All members of the team should be available to each other outside of daily scrum and other meetings.

share|improve this answer

When you run shift-work at a plant, it's because (due to increasing automation) you might have one operator tending to upwards of $1,000,000 worth of machinery. You had to finance that equipment and when it's not making parts, it's not paying for itself. Assuming you have the demand, if you work 3 shifts instead of 1 you can reduce the payback time by a factor of 3. Since one person's cost to the company might be 40k to 60k (fully loaded), the cost of workers (and the additional cost of running workers on a shift-basis) is less significant compared to the output.

Computers and cubicles, on the other hand, are cheap. Most development companies are more focused on finding the right developer, not maximizing the CPU usage of that person's development machine. If working sane hours makes it easier to hire experienced developers, that's probably a good tradeoff.

On the other hand, if you have people who want to work 4pm to 1 am and share a cubicle with someone else because they're a "night owl", why not?

share|improve this answer

How would expertise be handled in this situation? For example, does there have to be an expert in each shift? If not, then there may be an issue in responding to customer issues in a meaningful way as if the customer call comes opposite the shift where the expert usually works this could be a problem. If the expert works 4pm - 1am and the customer call comes in at 9am, does the customer really have to wait 7 hours for someone to start fixing something if the expert is the only one that fixes that part of the system? Similarly, for a late night call if the expert tends to work during the day in terms of this being a problem. While an initial response can be given, actual help may be another story which may or may not go over well with customers expecting prompt service.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.