We all have too much to do, and software development organizations are no exception. It's a fact of life that there are often more projects to do than there are people. How do you staff them?

Frequently, organizations do all of the projects, or more than they can handle, by assigning developers to multiple projects simultaneously. This looks fine on paper, but it ignores a central cost of software development: the cost of task switching.

In their excellent book, PeopleWare, Tom DeMarco and Tim Lister describe "flow," the highly productive state of concentration necessary for software development. It takes a software developer about fifteen minutes to enter flow, and during that time, very little work is accomplished. Every time a developer is interrupted, it costs the company fifteen extra minutes while the developer re-enters flow. So if your developers are being interrupted just four times a day, you're losing about an hour of work every day... and many developers are interrupted much more often.

Task switching has the same impact. To work on multiple projects simultaneously, developers have to switch back and forth between two (or more!) projects. Each switch interrupts the developers' flow, requiring them to switch gears and get back up to speed. And each project brings its own share of interruptions with it, reducing productivity further.

If you're in this boat, there's good news: you have an easy way to increase productivity! Simply assign developers to one project at a time. Although this will decrease the number of projects people are working on, they'll get done faster and your developers will accomplish more overall.

Sometimes developers experience a lot of interruptions due to responsibilities that can't be delayed, such as customer support or maintaining an old system. In these cases, "sacrifice a developer" by assigning one developer, changing weekly, to shield the rest of the team from interruptions. That one person handles all customer support and urgent maintenance requests so the rest of the team can stay focused. The time saved by reducing task switching makes up for the lost developer.

"Sacrificing a developer" requires that your developers have a working knowledge of each others' projects. That's a good idea anyway... you don't want work to stop if someone goes on vacation or gets sick. Be sure to change who's handling support duties regularly to keep everyone's skills fresh and to avoid burn-out.

The discussion here assumes a lot of small projects, the kind an internal IT organization might see. The cost of task switching is just as high for larger projects with multiple developers. I'll discuss that situation further in a future newsletter.

Some simple guidelines for increasing productivity by decreasing task switching:

• If your developers are working on multiple projects simultaneously, have them work on one project at a time.
• If your developers are handling a lot of urgent interruptions, "sacrifice a developer" by having one person, changing weekly, shield the rest of the team from interruptions.
• Ask yourself if all of the projects and interruptions are important and remove the ones that aren't.
• Consider ways of sharing knowledge amongst team members.

Task switching and interruptions are common problems with an easy solution. If your group has this problem, you have an opportunity to increase productivity. Take advantage of it!