A Sideways Look at Conway’s Law — A Terrible Blog Post #17
This journey to three hundred terrible blog post is hardly underway and we’re off to a very rocky start. I’ve been noticing that I’m inclined to just write about whatever is in my mind on the day that it comes to writing. I suppose that’s not the worst thing in the world. On one hand it feels vulnerable because I’m not really buffering and planning out what I want to talk about, I’m just revealing what’s in my mind on the day. On the other hand it’s not vulnerable at all because I’m just sharing what I think about and that can be a way of avoiding talking about who I am.
Well, today I’m going to try to pull together some outside concepts and talk about those. Specifically I want to mash together the concepts of Conway’s Law and message passing in Object Oriented Design. I was recently reading chapter 4: Creating Flexible Interfaces in Sandi Metz’ book POODR (Practical Object Oriented Design in Ruby)
If you don’t know what Conway’s Law is, then you may want to just parachute out of this terrible blog post because I’m bringing up a topic that nerds and software developers love. You may want to stick around though because I think I might be about to break my rule of not swearing. Kids plug your ears.
Here’s a sideways look at Conway’s Law: we’re constrained to produce shitty software because we’re shitty at communicating with each other.
Ok, that’s an absurdly exaggerated and negative way of putting it, but as I once said in another terrible blog post, sometimes serious matters need serious exaggeration. Ok let’s pull a diagram out of Sandi’s book next:
I can see two things when looking at these diagrams. I see both objects in a software system and I also see people in technology organization. This is a great opportunity to flex my terribleness and invent a word. Let me introduce you to ‘peebjects’ people object things!
On the left we have peebjects who know what they want to get their job done, but don’t know how to communicate with the rest of the system in order to get the information that they need, so they talk to everyone and anyone. On the right, we have peebjects who know who to talk to to get their jobs done, and what informations those objects need.
These peebjects on the right trust the peebjects to whom they are sending messages. They trust them in two ways. First they trust that there’s a well defined format for the message being passed—they trust that they’re speaking the same language. Secondly, they trust that the peebject will do the work and let them know with their response that the work was done.
For the sake of your sanity, Dear Reader, let’s step away from talking about peebjects and go back to just talking about people. In organizations these two aspects that we mentioned have two specific disciplines that we can talk about.
Speaking the same language = relationship
The first aspect was speaking the same language. The discipline for that can be called relationship. When two humans have a strong relationship, they can communicate with little effort. They don’t have to explain themselves overly much and they don’t have to constantly worry about formatting their message so that they will be understood by the receiver.
I wonder if I dare consider reflecting on all the ways that bad relationships result in poor messages being passed. Do I even need to talk about it? Here let me share a personal example.
A few years ago I was working in the kitchen to make brunch for my family. We’re a pretty large crew and there are a lot of mouths to feed, but that’s not particularly relevant to this story. What is relevant is that my wife was doing the pancakes on the griddle. We had a long standing history of disagreeing about putting three rows of pancakes on the griddle or two rows. Yes. Wait it gets better!
She got busy with making bacon or something, so I took over the pancake flipping. While I was doing that, I threw out some playful banter about how she should consider doing three rows of pancakes on the griddle. I thought I was being funny because I really didn’t care about how many pancakes were on the griddle. I argue about technical details all the time at work without really taking it personally. She took it differently…
Fast forward two hours later after some (much) yelling, some (many) tears and our children pounding on our bedroom door telling us to just stop arguing already. We finally resolved it, sat down to eat a cold brunch and it became clear that the problem had nothing to do with the pancakes and everything to do with the relationship.
The good part about it is that we were able to go through it and demonstrate to our children that human relationships can be messy and that it’s important to fight for them. We also learned that there were some deeper things that we weren’t talking about that needed addressing.
I just want to end this rant about relationship with a fascinating observation. If after fifteen years or so of marriage and working on our relationship we ended up having massive communication problems, why do companies seem to be rather superficial in their efforts to bring about deep channels of communication and strong relationships between their employees? Don’t they know that this is really difficult and should be taken seriously?
Maybe they also think this woman is going to get strong with those weights in her hands? Whatever they’re selling, don’t buy it.
Trusting to do the job = delegation
The second aspect was trusting that the person would get the job done and communicate back the result. The discipline for that can be called delegation. When two humans are practicing delegation then after the messages have been passed, they can trust the process of delegation to take care of the results. A manager who delegates successfully to a direct report will communicate clearly what is expected and be able to leave the decision making and the expected results to the report.
If you’ve been sleeping, Dear Reader, let me wake you up by slapping you with a slippery fish. Delegation works both ways. A direct report can and should delegate things to their manager. In fact they are duty bound to do so if they care about results. If they find that they can’t get their job done because of some blockage or miscommunication upstream in the organization, that manager should be held to account for taking care of that situation.
Good delegation has some basic properties:
- Be clear about expected results
- Be clear about boundaries (system resource management)
- Be clear about what could go wrong if the results aren’t met (exception handling?)
- Be clear about what resources are available (dependency injection?)
I could probably pull out some more basic properties but I’m way over time in the time I’m dedicating to writing. TL;DR -> Be clear. You can’t be clear without a relationship.
Answering an objection: It’s just data anyway
I can imagine some strongly data-oriented people in technology objecting to what I said way back about Conway’s Law. The objector might object that we can create non-shitty software just by talking about data and evidence and architectural patterns. There’s no need for relationships at all…
I will respond that you are correct sir! In the absence of emotional and connected relationships, we can probably make the most amazingly well architected software. Unfortunately though, said software won’t be interesting to anyone with a heart. Spock is a lie. Humans aren’t reason machines, and thank goodness for that. Compassion and empathy are some of our greatest super powers. Maybe we should exercise them more?
