Software Design is Human Relationships: Part 2 of 3, Waiters, Changers, and Sufficiency

In The Mountain People and The Forest People, anthropologist Colin Turnbull tells the stories of two tribes in Africa. The Ik were a hunter-gatherer society forced to settle in one inhospitable spot because their traditional lands spanned several modern countries. Turnbull describes in graphic detail the horrific behavior that resulted from starvation and deprivation. For contrast, the Mbuti tribe lived in lush rainforest where the basic needs of life were easily obtained. The resulting society was described as loving and supportive.

I read these two books my first semester in college and they changed my perspective. Human behavior, it seemed, was the result of context and incentives as much as choices. Critically, sufficiency versus scarcity changed how people acted and lived.

As I moved into the working world, I saw people act as if they were faced with scarcity even when they weren’t. I realized that sufficiency versus scarcity could be a matter of choice instead of just circumstance.

Waiters and Changers

In part 1 of this series, we talked about the difference between:

• Waiters — waiting for changes to the behavior of the system and
• Changers — changing the behavior of the system but also affected by and affecting the structure of the system.

Even though both groups’ incentives are ultimately the same, the short-term incentives they face diverge. Waiters stereotypically want more behavior changes faster, focused on either latency or throughput. Changers stereotypically want the structure clean and tidy (not all changers are the same — part 3 addresses the changer-changer relationship).

Imagine a coxswain demanding ever more strokes even as the boat fills with water. “More rowing will get us there sooner.” “We need to stop to bail.” “But that will get us there even later.”

This conflict between the desire of waiters for more behavior changes versus the desire of changers for more structure changes is the first human relationship that makes software design hard. How can both parties get their needs met and maintain a productive relationship in spite of the conflict?

Scarcity Versus Sufficiency

The conflict is real. One more structure change today is one less behavior change (except in those cases where the time required for a structure change and then a behavior change is smaller than the time required for the behavior change).

The conflict is real, but the attitude toward the conflict is a choice. To build a productive relationship, both sides first need to decide if behavior changes are scarce or sufficient. If behavior changes are scarce, then the relationship will deteriorate.

To say that behavior changes are sufficient is not to say that everything will get done. Many desired behavior changes aren’t good ideas. Some of those can’t be identified until after they have been deployed. Choosing behavior changes is not a science. More is probably better. All is impossible. Some is probably enough.

That’s the foundation of a productive working relationship between waiters and changers — choosing to see that there are enough behavior changes even when structure changes sometimes take priority.

Interleaving Behavior and Structure Changes

Beyond identifying the benefits to be gained from sharing an attitude of sufficiency I’m afraid I have little concrete advice for achieving it. Despair not, fellow changers. There is something you can do as a software designer to improve your relationship with waiters.

Imagine that on the one hand you have behavior changes and on the other you have structure changes. Literally. Behavior changes on one hand and structure changes on the other.

Now comes the question of how to sequence the changes. Do you make a bunch of structure changes before you make behavior changes?

The relationship problem with this strategy is the long wait before any behavior changes appear. It’s hard to stay patient when you can’t do anything to speed up the process.

At the other extreme is only making structure changes when there is no alternative.

From the waiter’s perspective, it looks like everything is going quicky-fine when suddenly the changers ghost. There is an unprecedented extended pause during which nothing seems to be changing. Any good will from the rapid early sequence of behavior changes evaporates.

So, here’s what you can do — a little of this, a little of that. To the degree you can interleave behavior and structure changes, it appears to the waiter the flow of behavior changes is slow-but-steady.

Loss of control is one of the big fears affecting the relationship between waiters and changers, and a steady flow of behavior changes contributes to a feeling of control.

Interleaving behavior and structure changes is a tradeoff. Structure changes would certainly take less elapsed time if done all at once. They might take less total time if done all at once. Relationships trump efficiency, since without an effective waiter-changer relationship all that efficiency is a quick trip to nowhere.

And Then…

The subject of human relationships is vast and I am by no means a competent practitioner, much less an expert. The good news is that:

• You (and I) can get better with practice and
• You don’t have to be an expert. “Better than those who aren’t trying” is good enough for most purposes.

Three observations from this essay may be enough to get you beyond “those who aren’t trying”:

• Acknowledge that incentives don’t align.
• Choose together to treat behavior changes as a sufficient resource.
• Work as a changer to change structure invisibly, making even the largest structure changes in small, safe steps.

The relationship between waiters and changers is not the only important human relationship in software design. Changers also relate to each other, and their incentives sometimes clash. A changer focused on behavior changes can easily feel thwarted by a changer focused on structure changes. But that’s the topic of part 3.