Sign In

Communications of the ACM

The business of software

A Little Queue Theory

A Little Queue Theory, illustrative photo

Credit: Alicia Kubista / Andrij Borys Associates

So, how full is your in-box? How many tasks on your to-do list? Take a look at that calendar—any open spaces? No? That's good, isn't it? The more work that is in the hopper, the more must be getting done, right? Empty spaces in the plan means less is being achieved, right? Well, maybe not.

It seems to be an axiom of modern projects that for every project team member, every minute of every day should be filled with assigned tasks. I know project managers who boast of loading themselves and their subordinates with way more than 100% of available time. It is not uncommon for people to be juggling 10 or 20 tasks concurrently. As one who admits to poor multitasking capability, I have always thought there is a downside to having too much on one's plate at one time. But it is difficult to argue against this overloading of effort when the equation is more work on the task list means more gets done. But is that true?


Rudolf Olah

There's another side to this; politics. If everyone isn't seen as doing as much work as possible, they could get in trouble (or at least their manager might). So the queue and workload are *visible* while the thoroughput isn't as visible. If no one is held accountable for how long the uncompleted tasks/backlog is becoming, then it will continue to be ignored though most bug/issue trackers will give you this valuable statistic.

Phillip Armour

You are right. Many of the overloading problems result from the need to be seen to be busy which often has a political source. But even if tasks arent issues queuing theory shows that when people are loaded close to, or over, capacity bad things are likely to happen downstream. Most projects track delays in task start or task completion and sometimes replan when the variance gets large. But I have never personally seen a project explicitly measure the size of its work queues to use as a leading indicator of project delays.

Displaying all 2 comments

Log in to Read the Full Article

Sign In

Sign in using your ACM Web Account username and password to access premium content if you are an ACM member, Communications subscriber or Digital Library subscriber.

Need Access?

Please select one of the options below for access to premium content and features.

Create a Web Account

If you are already an ACM member, Communications subscriber, or Digital Library subscriber, please set up a web account to access premium content on this site.

Join the ACM

Become a member to take full advantage of ACM's outstanding computing information resources, networking opportunities, and other benefits.

Subscribe to Communications of the ACM Magazine

Get full access to 50+ years of CACM content and receive the print version of the magazine monthly.

Purchase the Article

Non-members can purchase this article or a copy of the magazine in which it appears.