Musing: Aligning Authority & Responsibility

As Tidy First? comes in for a landing I’m starting to think about the next book. If you haven’t been following along, this series of books is about software design as an exercise in human relationships. The scope narrowed as I progressed.

I started by thinking about the Waiter-Changer relationship. The Waiter wants the software to behave differently but can’t do anything to make that change happen. Having requested a change, the Waiter waits (hence the name) for the change to happen. The Changer is the person (or organization) that can change the behavior of the system.

The relationship is fraught because of mis-aligned incentives. The Waiter is impatient. I told you what to do. What’s taking so damn long? The shorter the wait the better. The Changer has to live with the consequences of all those short cuts & messes. While the Changer wants to get this request done quickly, they also know that tomorrow there will be another request & the day after another, so the Changer want to take enough time so tomorrow & the day after will be tolerable.

In the long run the incentives are aligned—both parties want to create as much value as possible. In the short run, though…

When I started writing about the Waiter-Changer relationship I realized I didn’t have enough foundation upon which to build. First I would have to write about team software design, where by “team” I mean the Changers working together.

Changer-Changer relationships are also fraught because of mis-aligned incentives. We (we Changers that is) can get into fights over what the design should be. We can get into fights over how much design is needed now versus later. We can get into fights over who should do the work. Even among geeks speaking the same geeky language software design is still an exercise in human relationships.

As I walk the hills of San Francisco & think about Changer-Changer relationships the theme I keep running into is aligning authority & responsibility. Take an API change, for example. You’re providing an API that I use. You want to change that API, for whatever reason [Is there a canonical list of reasons to change an API? Must investigate.] Anyway, you want to change the API & from your perspective that’s a good thing.

What about me? If I don’t have immediate use for the new capabilities of the new API, I’m likely to be grumpy. Why do I have to change? This isn’t buying me anything? Can’t you quit fiddling with stuff & causing me problems?

The principle of aligning authority with responsibility suggests a relationship-positive response. If you have the authority to change an API, causing work in other parts of the system, then you should also take responsibility for doing that work.

If you change the API in a way that causes me to have to do work, you start by educating me on the change. You might come to me & we do the work together. You might offer an automated refactoring to change all the call sites without me even having to do anything. In the end, you and I have a stronger relationship than before the change.

Contrast this with a “not my problem, sucker” approach. You change the API, my code breaks, I get yelled at, I have to interrupt my plans to fix things, I’m grumpy, and on down the spiral. Not relationship-positive.

Contrast it also with the “deprecate forever” approach. You change your API, but retain backwards compatibility. Now you have to work slower as versions N-1, N-2, and so on pile up. I get the pretend nothing has changed, but transfer the cost of that illusion to you. The organization has a host of “off the books” work needing to be done but no one is responsible. You’re grumpy.

The challenge of adopting “align authority & responsibility” as a principle is that organizations are expert at separating the two. People with power grab authority & push responsibility down to those with less power. So maybe this is all doomed, but my geeky heart loves how clearly “align authority & responsibility” predicts a relationship-positive path.

Now back to finish TF?