Software Design is Human Relationships: Part 1 of 3, Perspective

Actually 2 human relationships, but we’ll get to that.

Easy Part

Can you:

• Recognize the unnecessary pain caused by your current design?
• Imagine a new design that would alleviate that pain?
• Finding stepping stones on the path from the current design to a pain-less future?

Great. You have the technical skills to design software. But…

But challenging though software design is technically, the technical part is not the hard part. The hard part of software design is navigating the human relationships, full of conflict and conflicting incentives.

Programmers are stereotypically bad at navigating relationships and relationship conflict. I don’t mind this stereotype because it describes me pretty well. Designing software and helping others design software led me, over and over until I finally accepted it, to the conclusion that the human part was the hard part and absolutely necessary.

Here, then, in three geeky pieces, is my current understanding of what the human relationships are in software design, why conflict is built into those relationships, and what behaviors can help a software designer find a way forward.

The story begins with perspective.

Waiters and Changers

(The world isn’t this simple, but imagine for purposes of argument that it is.) There are two kinds of people who care about a software system:

• There are people who care about the behavior of the system, who want the system to behave differently, but can’t actually change the behavior for some reason. We’ll call them waiters.
• There are people who can change the behavior of the system. We’ll call them changers.

(Some folks want a Waiters Island and a Changers Island and a narrow rickety bridge between them, others want the same person to be both waiter and changer [in which case the conflicts I describe are driven into one brain], and some want waiters and changers to sit and work together. For purposes of argument and because this is how many teams around the world are organized, we’ll assume that they are different people and yet working together.)

Behavior Cycle

Changers and waiters cooperate to operate the cycle of behavior changes:

Incentives are well aligned in this picture. Both parties want to optimize:

• Latency if the feedback is frequently surprising.
• Throughput if the feedback is usually confirmatory.

Structure, Too

Changers have to cope with an additional constraint, the structure of the system. (By structure I mean both the elements of the system and their relationships and also the tooling in the path from “I made a change” to “We’re creating more value”.)

Sometimes, the “tidy first” scenario, the quickest way to change the behavior is to first change the structure so that changing the behavior is easier. (Foreshadowing: what if changing the structure doesn’t pay off this time but it will or it might the next time?)

Another path to structure changes, the “tidy after” scenario, is when behavior changes lead to the desire for structure changes. The code is messy. The technical debt is piling up. The structure could be better.

Changers are not (or shouldn’t be, from my geeky changer perspective) mindless drones carrying out the unambiguous, omniscient demands of the waiters. Sometimes, the structure of the system will itself suggest ideas. A new structure might make an idea worth implementing simply because it has become easy to implement, the adjacent possible. We cannot, after all, perfectly predict the consequences of a change (if we could predict we wouldn’t need feedback, and no one is arrogant enough to work without feedback —well, almost no one).

Waiters Versus Changers

Structure changes are as inevitable as behavior changes. Conflict begins. Waiters care about behavior changes. They only care about structure changes in the long run, for example when deferring structure changes has led to a slow down in behavior changes.

Changers care about structure changes. Pride, frustration, aesthetics, desire for future ease, and curiosity all encourage structure changes.

In part 2 we will explore the conflict between waiters and changers as they negotiate the relative sizes and timing of investing in behavior and structure.