The Waiting List Pattern

In any line of business, lists are not too far away. A lot of spreadsheets are nothing but glorified lists. Even in application programming and user interfaces that serve these businesses, no matter how different their appearance might be, as collections, tables or grids, lists are abundant. Many software developers have mixed feelings about their relationship with lists, mostly in the form of backlogs and progress tracking boards. In fact, there are many endeavors to get rid of lists altogether, which, in all fairness and on many occasions, makes sense to me. Despite that, the reason lists are still popular is because they tend to bring order to chaos, thereby relieving one from stress and maintaining one's focus. They act as a piece of memory, aiding in remembering things. They can be as long or as short as they need to be and can be used to either decompose larger tasks into smaller ones or aggregate smaller tasks into larger ones. They are pretty easy to scan too. Once you start looking for lists, you start seeing them everywhere.

Even though not all lists are created equal, generally speaking, they're much more like queues. Take health care, where it's not uncommon for people to be put on a waiting list, waiting for a transplant, an appointment due to a discipline being understaffed, or a form of treatment that may or may not yet be available, or even medication for that matter. Take commerce, where people wait for an item in short supply in the order of their application. In human resources, a vacancy for which there may be too many applicants, some of which might end up on the waiting list, waiting for the next opening. In public or social housing, people in need of a living accommodation may be put on a waiting list due to the limited availability of suitable accommodations. Even in education, school systems cause people to be put on a waiting list, shuffled around according to various admission criteria. The recurring theme in these examples, and there are many more like this, seems to be that demand > supply but more importantly that there is an aspect of temporal decoupling between stating a demand and a supply becoming available that fulfils it.

My first encounter with this pattern was when working on scheduling software for hospitals. We called it a pending list because waiting list already had a specific meaning in health care. Any critical resource would get a schedule, be it a person, a thing, or a place, and along with each schedule, one would define what availability looked like. Inevitably, over time, the resource's schedule would get changed, and as a consequence of that, so would current and future availability. Now, an increase in availability usually did not have any side effect other than the ability to schedule more appointments. However, a decrease or time-wise shift in availability had a bigger impact. One has to realize that appointments had already been scheduled when the previous availability was still in effect. We'd do our best to try and fit every appointment, as it was, back into the new availability. But this simply wasn't always possible, the simplest case being throwing away all availability. Of course, we told that end-user fiddling with the schedule "Are you really sure you want to make X appointments pending?". Despite the warning, there were times these changes were legitimate, so we'd allow them. And so, as a result, some appointments would move to that pending list. But why? Why didn't we automatically book these appointments in the schedule of another resource that had availability to fit one of them, or why not schedule it at another time? Maybe that other resource didn't want to perform them, maybe there was no other resource with enough availability, at least, just yet at that particular moment in time the original schedule got changed, or maybe that patient didn't want to or couldn't come by at that newly proposed time, and I'm not even talking about the cost of letting everybody involved know ... there are many more reasons why automation would have been a bad idea - complexity better left to be handled by humans being the main one. I can understand, even empathize with a developer's eagerness to solve every problem thru automation, but sometimes you have to know when to stop.

There's another reason why having that waiting list, that queue, in between is useful. That is, when the person putting things on the list is not knowledgeable enough or not authorized to take things from the list and put them in the appropriate place. Coming back to the scheduling example, while a resource owner can change his or her own schedule, that doesn't imply they can reschedule the appointments in another resource's schedule. Yet another reason is that the one change, causing things to be put on the list, is part of a bigger set of changes, which, for all we know, could be performed collaboratively by a group of people, and those changes could be performed at different moments in time. I'll gladly acknowledge that handing off work in this way may not be optimal from a process point of view, but it does offer the people involved a tool to park things and take it back off of the list as and when they see fit.

I've seen people use the waiting list pattern as an excuse to either not automate or not explore. Like anything else, it can be abused. Granted, sometimes not automating is good enough. For those of you that read the to-do list pattern, thinking "well, isn't this the same"? From an implementation point of view, for sure, a to-do list and a waiting list will manifest themselves in a very similar - if not exactly the same - way. It's mainly the why that's different. Whereas a to-do list mainly focuses on capturing work we don't yet know how to automate, a waiting list tends to focus on the temporal decoupling of the work, allowing the people involved ample time to deal with it and to segregate responsibility, if necessary.