The To-Do List Pattern

It's been a while since I've last put effort into writing. Sometimes a hiatus can do wonders in coming up with new content. At least, that is what I kept telling myself. "Honing the art of postponing" so to speak.

Content which I sense has been lacking in the broader software development community, at least in the circles I frequent, is one of the patterns in line of business we encounter, be they analysis (what) or design (how) related. Over the years I've spent most of my time dealing with clients that have a desire to automate either their own or (more often) the business needs of their customers. Frankly, it's quite a daunting task to be confronted with. Going from zero to hero in a certain space can take between days and years, despite all one's experience, especially if it's one's first foray. Oddly enough, for me, the more interesting ones are those that take copious amounts of time to get to grips with, uncovering all the subtleties in the process. There's a sense of fear, uncertainty and doubt that often goes hand in hand with these learning experiences - fear to fail, uncertainty about what one is doing or how one is going about it, doubt what the best path forward is. Like a chameleon, one adapts to the environment, the people, the hidden agendas, the practices and approaches, the way of thinking, the organizational maturity, the distribution of focus between problems and solutions, ... countless factors one has to take into account. Offering ample options along the way seems to be the recurring outcome theme. Slowly but surely, over the course of time, you learn to sense and how to respond to a given situation.

But there are times where we simply do not know how to model or automate. If - like me - you've been confronted with this and are persistent in wanting to understand, there comes a time where you hit a wall. The reasons might range from a disconnect with actual users or not knowing who your users are and what they want, over the functionality not being very clear due to a limited understanding at the time, or actual automation being perceived as a risky and expensive investment. This list is not exhaustive by any means. One could argue that this type of problem can be solved by doing more analysis, and I'm sure that in some situations that might actually turn out to be true. But performing more analysis can also have a stifling side effect, giving the impression that we're not making progress or are embracing waterfall and big design upfront. Maybe the will to do more analysis is lacking. Or maybe we miss a feedback loop and more analysis is not the appropriate answer. Or maybe, just maybe, automation is not desired at all. But ... we don't know.

In cases like these one of my approaches is to introduce what I call a to-do list. Not very original, I'll be the first to acknowledge, but having implemented this on multiple occasions to solve a similar problem, third time's a pattern 😃. The purpose of this list is to capture the tasks that would otherwise be automated and surface them to those who now have to perform those tasks manually. The list acts as a logical separation and can manifest itself in many ways, depending on what those that have to do the work are used to or are willing to deal with. Think support tickets, email, text or chat messages, a dedicated dashboard, etc. For this approach to work, we need people who are willing, able, and available to perform these tasks, and the tasks themselves should not require immediate feedback, though they can come with priority or due times if the situation calls for it. We can embed these tasks directly in our model, thereby making this aspect of uncertainty explicit. We can translate these into code, as documents, messages, commands, or fairly dumb entities, store them, and surface them as new ones become available. This in turn will give feedback, e.g. such as how often they occur, but also how they get performed, what procedures people follow in doing so, hopefully uncovering those missing pieces of information that blocked us earlier.

Now, this to-do list is an intermediate state, a means to an end. The entire point is to learn if, how, when, and what to automate. Once we do settle on automating some of them, we can gradually stop them from entering the list to begin with as we replace them thru automation. For other tasks, the effort of automation may simply not be worth it, and keeping a manual workflow is all that is needed. The perception may be that the list is linear and tangible, but in my experience, it is far from it. In fact, depending on who does the work, the list may get split into multiple lists, we may use some sort of self-service or automatic assignment and the functionality may even be augmented by simple things such as marking the task as done, or by more complex things such as installing a triage process to run through the tasks before actually doing them. Still, you'd be right in thinking this is a commodity.

This notion of dealing with lists is fairly ubiquitous in a lot of businesses. There are many more list patterns out there, often tied to a particular domain. In a future blog post, I'll go over two more patterns I've encountered, namely the quarantine list pattern and the waiting list pattern.