The Story of A
Software design is truly an exercise in human relationships
A was a new student when they started complaining about their teammates. “Don’t they see that we need this & that & this & that? They need to let me make these changes.”
The business domain A & their team worked in was incredibly complex. The current system had been built emphasizing the behavior of the system & not the structure. As always, this led to a structure not well suited for further change.
A had been working in the system long enough to have ideas for how things could be better. There needed to be a hierarchy of these things & a factory for those things & a factory for the factory because eventually we wanted to do this & that. The diagram of the system as A imagined it was full of boxes & arrows.
The team was having none of it. They had features to ship. A’s pull requests were piling up, unreviewed. Stale PRs led to bigger PRs, further slowing the pace of structure change. A was, reasonably, frustrated.
Reframing
As we worked together, I gave A (& this situation of imbalance between behavior & structure change is common in my experience) a set of tools to gradually address their frustration & that of the team.
Doubt
It may seem strange, but doubt sharpens design. Okay, I have a vision for a new structure. I’m sure it will be better. But will it? Big changes to structure are almost always a mistake even though big changes in direction of the structure are often correct. A was right that the current structure inhibited behavior change. Would their proposed changes make behavior changes easier?
Hope & vision fuel structure changes but hope & vision can become ends in their own right. Hope & vision feel great, especially when you’ve been neck deep in Coupling Hell. Just because you have a vision for a better structure doesn’t mean that structure will deliver. There will still be coupling. Is it better or worse than today’s coupling?
Of all the changes A wanted to make, which of them were certain to make features easier? Which might have no effect? Which might actually make change harder?
Empathy
Healthy skepticism about your own design vision helps you see the current & proposed structures from the perspective of those living in those structures. You’re all cooking in the same kitchen. They know where to find the knives. If you move the knives, your fellow cooks are going to have more trouble at first, not less, even if the knife location improves.
Once you apply doubt to your desired structure, you’re ready to begin seeing it from the perspective of those whose work you are (one hope temporarily) disrupting. Software design is not just the software elements & relationships, it’s people too.
A had 5 or 6 big changes to make. Which would benefit their teammates immediately? Increase the priority of those changes.
Slicing
A had a diagram of the system structure today & a diagram of the system structure as they imagined it. They weren’t done. How to get from here to there? One gigantic change? Never going to happen. No one would approve it. Force it down the team’s throat & they’d (rightly) rebel.
I challenged A to imagine different paths from now to the future. Put in this level of factory & then that? Or the other way around?
A had many options for slicing & sequencing their proposed structure changes. Many options for prioritizing changes:
Most likely to improve behavior changes most
Least provocative
Least disruptive
Most likely to improve behavior changes soon
As with music, it’s not just the notes, it’s the notes in a row that communicate.
Conclusion
I’d like to say that practicing doubt, empathy, & slicing transformed A’s work. I’d like to & I can. Instead of being stymied by teammates, A became a resource for them. A assisted with gnarly behavior changes, further refining the design. Sometimes A would tidy first, further incorporating the team with design evolution. PRs got smaller. Reviews came promptly.
Software design just focused on the software can already feel overwhelming. Including people in the picture can induce panic overload. It need not. Doubt, empathy, & slicing may be new skills, but they are just skills. You practice, you improve.
For some reason the "Doubt" part reminded me of "dialectic" (as a truth searching process). Which I am not a specialist of (yet), but made me think that dialectical thinking and dialectical logic could maybe provide some interesting ideas to be translated to our line of work.
I don’t comment very often, but I read these chapters the moment they come out. They are short, interesting, and almost always contain an interesting idea or angle that I can use. Thank you!