How Feedback Loops and Interpretive Labor Help Us Develop Better Software

Information naturally flows from those who have more power to those who have less.

That is, some kinds of information do. Those who study surveillance capitalism or worker surveillance will rightfully point out that when there is money to be made from carefully watching those you have power over, information seems to flow the other way. But I am not tackling surveillance capitalism or worker surveillance in this post. Instead, I’m focusing on the specific kinds of information which emerge from imaginative labor and interpretive labor.

Imaginative labor is the work of imagining how the world could be, building models, theories, product designs and plans. Imaginative labor creates imaginative information---information about the model or plan to be implemented. Interpretive labor is the work of actually adapting a model, product or plan to reality, and it creates interpretive information---information about the gaps between model and reality.

This diagram shows what information flows might look like in a typical organization that develops software:

The diagram shows imaginative information as solid lines flowing from owners to their employees (developers and support staff) and from those who are designing and supporting the software to users. Developers (product managers, designers and engineers) send imaginative information to users through their decision decisions, while support staff send it through direct communication. Regulators send information to all parts of the system but tend to communicate most directly with organizational owners.

There are two dotted lines representing interpretive information. These flows happen against the power gradient and do not arise naturally, but must be constructed. Users are the primary performers of interpretive labor in software systems. I added flows of interpretive information from users to support staff, and support staff to developers, because many software companies will create at least minimal versions of these channels. For instance, some organizations allow support staff to create tickets for developers to consider, based on user feedback, as discussed in the previous post.

Some organizations do far better than this, creating many more channels for interpretive information to flow. Others are much worse, and actively try to suppress information.

In an ideal world, interpretive information is constantly incorporated into subsequent imaginative labor. The model is adjusted to fit reality. But, in hierarchical systems, this doesn’t happen naturally. Instead, those at the top perform imaginative labor and pass the resulting imaginative information down through communication channels greased by power. Meanwhile, those at the bottom perform interpretive labor, adapting the model to reality, with no way to share the resulting interpretive information back to decision-makers high in the hierarchy.

This post will discuss the ways we can do better---the ideal world. A follow-up post will describe all the ways things can go terribly wrong.

What is the ideal which we are aiming for? I define “utopian” software as that which meets the needs of its users as effectively as possible, while minimizing any harms to users and non-users. Because users are best positioned to know their needs and to understand the harms they’re experiencing, ideal software development highly values user feedback and is careful to incorporate it into every level of development. To use the terminology introduced above, ideal software development incorporates interpretive information into decision-making processes at all levels.

The rest of this post is a list of best practices which, if combined, bring us closer to our ideal system. I have ordered them from the smallest scope to the broadest.