Ben Northrop

Decisions and software development

Unclosed Loops and Developer Frustration

October 16th 2017

Tolstoy once wrote, "all happy development teams are alike; every unhappy development team is unhappy in its own way". And after 20 years as a programmer, I can attest to at least one sure-fire route to unhappiness:

It's the beginning of the sprint. Everything's been planned, estimated (if that's how you roll), and assigned. You have a few features on your plate, and are eager to get going. Starting with the most critical one, you dig in for a day, get a plan together for how to tackle it, and begin coding.

Another day passes and you get about halfway through when the project manager swings by your desk. "Hey", he says, "I know you've already started, but a business priority has changed, and we need you to work on this different feature instead. Finish this new one off now, and then you can get back to your original work".

I'm not sure about you, but this drives me freaking crazy (at least it does when it happens often). But should it? I mean, I'm being paid by this company, and it's up to them to set their own priorities, right? If they decide there's more value in a different feature, that's their call. Further, I'll get back to the original feature eventually, and if I don't, who cares - I learned a few things in the process of digging in, and probably have a better grasp of the application as a result. What reason do I have do be frustrated? And yet I am...

This internal tension has plagued (or at least puzzled) me forever. Why do I hate leaving tasks unresolved so much? And I think its not just me - most of my colleagues seem to get just as frustrated when it happens to them. But why? Recently, while reading the book Irresistable, I found an explanation.

In psychology, there's a well known cognitive bias called the Zeigarnik effect. It states, simply, that an incomplete or interrupted task will be remembered better than a complete one. The phenomenon was coined by Bluma Zeigarnik, a psychologist who noticed that waiters had better recollections of orders that were unpaid. As soon as an order was completed, the waiter effectively flushed it from memory. In her paper Finished and Unfinished Tasks, she explains:

"When the subject sets out to perform the operations required by one of these tasks, there develops within him a quasi-need for completion of that task. It is like the occurrence of a tension system which tends towards resolution. Completing the task means resolving the tension system, or discharging the quasi-need. If a task is not completed, a state of tension remains and the quasi-need is unstilled."

This hits the nail on the head for me. When I start development of a new feature, there's a non-trivially strong force within me that wants to drive it to completion. If I'm asked to table that feature in favor of something different, my brain can't completely let go of the original task and so I can't fully focus on the new task at hand. The details of the original task are still churning in some background process in my brain.

Further, my guess is that the Zeignarnik effect is probably cumulative as well. The more tasks interrupted, the greater the tension and frustration. And for some, this is the rule rather than an exception. You get into work intending on finishing off some feature, but then get pulled into a meeting to discuss something different, and then get pulled out of that meeting to work on a production defect, and so on until the day ends and almost nothing was fully resolved. Ultimately frustrating.

Adjustments can (and probably should) be made in an organization to avoid this effect, since the effectiveness, mental clarity, and possibly even sanity of their developers depend on it. First, of course, we should strive to limit interruptions and let developers close open loops before forcing new ones upon them. Many teams have already started doing this through the adoption of Kanban and work-in-progress limits. Additionally though, in environments where interruptions are rampant, perhaps tasks could be designed to be as fine grained as possible, allowing developers to finish something before being pulled off to work on the next. Lastly, it's possible the best solution might just be to strive to overcome our innate mental wiring - when you get frustrated over switching away from a task, just acknowledge it's just the Zeignarnik effect, and do what you need to do.

Anyway, I'd be interested to hear about your experiences. Is the Zeigarnik effect real, and does it cause frustration? What do you or your team do to address it?

I believe that software development is fundamentally about making decisions, and so this is what I write about (mostly). I've been building software for about 20 years now, as a developer, tech lead, and architect. I have two degrees from Carnegie Mellon University, most recently one in philosophy (thesis here). I live in Pittsburgh, PA with my wife, 3 energetic boys, and dog. Subscribe here or write me at ben dot northrop at gmail dot com.

Got a Comment?

Sign up to hear about the next post!

If you liked this article and want to hear about the next one, enter your email below. I don't spam - you'll only receive an email when there's a new post (which is about once a month, tops). It's all low-key, straight from me.

Comments (2)

Trish isn't my real name
October 16, 2017
Sometimes I fantasize of being deaf and working from home.

That way, all bug reports and feature requests would have to be written down, documented, and prioritized.

And no, boss, your news blurb about a slick deal on Amazon is not more important than whatever I'm trying to focus on.
October 19, 2017
Unfortunately, this is the all too real everyday experience of many software workers.

There are some good words to describe the problem and some solutions in the lean software movement. "Lead time" is the time that it takes between an idea being conceived and its delivery as a real fully-functioning feature in production to a customer. "Waste" is any activity not promoting advancement towards delivering to the customer. One example of waste is "context switching" which is what you've described here. "Flow efficiency" is the measurement of actual time spent advancing towards customer delivery divided by lead time. In other words if lead time is the 10 business days in a typical two-week sprint, and 4 days are spent on actual valuable activity towards the delivery of the feature, then flow efficiency is 40%. In organizations that measure flow efficiency, 40% would be considered pretty good. Most orgs can't hit 15% because there's so much email-checking, pointless status meetings, HR paperwork to fill out, staff surveys, existing maintenance, etc.