Software Design is Human Relationships: Part 3 of 3, Changers & Changers
- All changes to a system are either changes to its behavior or its structure.
- The incentives of those waiting for changes to behavior (“waiters”) can temporarily diverge from the incentives of those changing the behavior (“changers”), because the changers must juggle behavior and structure changes.
- A path to maintain a strong relationship between waiters and changers is to agree on a sense that there will be enough behavior changes and then interleave behavior and structure changes so something new is always appearing.
Changers and Changers
The relationship between waiters and changers isn’t the only relationship suffering from diverging short-term incentives. Changers can disagree with changers about what needs to be done next. Resolving these disagreements can be difficult because both sides can be correct in their local frame. Maintaining strong, productive relationships between changers is second only to maintaining relationships between waiters and changers as necessary prerequisite to realizing the value of software design.
Disagreement comes in two flavors:
- Structure disagreement
- Interference between structure changes and behavior changes
Structure
You want to hack our system into services and I think operability is better served by a monolith. What do we do when I think the structure of the system should go in one direction and you mistakenly think it should go in another? Sorry, what if we are enjoying a diversity of opinion?
We still have to do something next, even if that something is to delay structure changes. This is the problem of one structure changer disagreeing with another.
The first step is acknowledging that our relationship is more important than the design of the system. As long as we have a productive working relationship we can move the design in any direction. When our relationship breaks down we don’t get anywhere.
There are many flavors of resolution that don’t look like winner/loser:
- Try both. Treat design changes as reversible. What would one little service look like? What would one cleaner internal API look like? Work together on both options. Make the experiments short. You’re both bound to learn something.
- Create optionality. Rather than change the structure one way or the other, isolate the rest of the system from the choice. Again, work together on this. You will have to go through all affected areas of the system and analyze impact.
- Implementors rule. The Implementor’s Rule is that implementors rule. If you can’t agree and you don’t want to work together, agree a scope and whoever cares most goes and works within that scope.
Interference
Okay, so you just want to go implement the next feature and along I come and say no no no this should be designed completely differently. Even if you are right that the new structure will eventually make my behavior changes easier to implement it’s not eventually, it’s today.
First, acknowledge that our incentives diverge in this moment. It doesn’t help to pretend that we agree when we don’t.
Second, as the structure changer I need to acknowledge that I am placing a burden of learning on you. I think it’s worth it, but if I’m asking something of you I better be prepared to offer something to you.
Here are some ways a structure changer can work so as to maintain productive relationships with the behavior changers they affect:
- Work in steps. Don’t make big changes. Make all changes in small, safe steps. Sort the changes to realize some benefit for behavior changers early.
- Work together. Sit down together for the next behavior change. Yes, this “slows down” structure changes, but you maintain relationships and generate valuable feedback that will improve the structure.
- Migrate. If I change an API, I should go change all the callers (see also aligning authority and responsibility).
Conclusion
Software design is a human relationship problem with interesting technical aspects. Geeks relating to geeks requires as much effort as geeks relating to their systems. Maintaining relationships may be hard and confusing and frustrating to geeks (I could be projecting here but yeah no I don’t think I am), but if you want your technical skills to matter you really have no choice but to improving your people skills.
