Sources of Friction, Sources of Harmony

Team Empirical Software Design

Software design is an exercise in human relationships. Software design decisions harm geek-to-geek relationships, but software design can also help heal geek-to-geek relationships. The second book in the Empirical Software Design series explores how software design connects to geek-to-geek relationships.

(I don’t have a clever name for the book yet. It takes a while for those to emerge. If you see a line in what follows that tickles you, let me know.)

Geek-to-geek

By “geek” I mean someone who can change the system in a way visible to others. Programmers are definitely geeks by this definition. Product managers are not (relationships with product managers are the topic of book 3, also unnamed at this juncture). Visual designers are somewhere between.

I’m going to leave the boundaries of Geekistan a little vague for the moment. So far I see no harm in this, but we’ll see. For now think, “I’m a programmer, you’re a programmer, our work affects each other.” I’ll let you extrapolate from there.

Friction

How does software design introduce friction into geek-to-geek relationships?

• Lumper/splitter. Some folks like larger elements (those with more sub-elements), others like smaller elements. If you’ve ever seen a giant file & thought, “This needs to be like 10 files,” you may be a splitter. If you’ve ever seen a sea of composed functions & thought, “Once I inline all these useless little functions I may be able to understand what’s going on,” you may be a lumper. Structural progress for a splitter is structural damage for a lumper.

• Timing. Timing is a consistent theme in Empirical Software Design. Not just what, but when. If I want to make a structure change now & you want to wait, even if we’re talking about the same change, we are in conflict.

• Time frame. We can disagree about now versus later. We can also disagree about “prepare for tomorrow” versus “prepare for 10 years from now”. (Senior geeks are particularly prone to looking too far ahead, at least from a discounted cash flow perspective.)

• Structure versus behavior. If I’m primarily concerned about structure & you’re primarily concerned about behavior, we’re going to have to negotiate if we want to make progress together.

• Separate working. Taylor has heaps to answer for. Divide-and-conquer is such an unquestioned assumption, and unlikely to be effective in the integrated world of geeks. If the structure change you care about interferes with the structure change I care about, we’re going to step on each others’ toes. Ouch.

• Incentives. You like seeing users’ eyes light up when their needs are met. I like a long sequence of tiny changes that add up to massive impact. We’re going to be in conflict. Divergence of your manager’s incentives & mine amplify our conflict.

• Experience. If you know Elixir well & I don’t, then what seems trivial to you may seem impossible to me.

• Power differentials in general. You being senior & me being junior constrains my behavior. I’m not going to like that (just speaking for myself here).

• Genuine differences of opinion. We can take away all of the above factors & still disagree on what to do next.

Harmony

Reviewing the above list & I’m amazed we’re not punching each other all the time. Time for some hope. What brings geek-to-geek relationships into closer harmony?

• Shared accomplishment. If you & I come together to accomplish some goal, our relationship grows. We trust each other more. We anticipate future accomplishment.

• Shared principles. If we roll back from time to time to discuss the principles behind our work, we can recall those principles in moments of conflict. Discounted cash flows come in handy, for example, when discussing timing conflicts. However, we need to both understand & agree on the importance of discounted cash flows.

• Shared vision. If we are both emotionally engaged in the same big goal, we are more likely to set aside our differences.

• Shared rhythm. Another bothersome consequence of divide-and-conquer is that we can get off rhythm. If we share a rhythm (hourly, daily, weekly, monthly, quarterly), then we have natural synchronization moments.

• Favors. Exchanging favors deepens bonds. Helping with a structure change is a geeky bid for connection.

• Lessons. Similarly, if I learn something from you, I trust you more, I cut you more slack, I’m more prepared to bend. “Oh, is that how that works? Thanks!”

• Socialization. If we know each other as more than code hoses, we are willing to work through conflict.

Looking at this list I’m struck by how many of these items are “inefficient”. The short-term, small-scope, act-like-they-are-just-machines response is to suppress these behaviors. And then you get what you get from grumpy, conflicted, paddling-to-their-own-beat geeks.