Consistency, cohesion, and coherence

My colleague Micah introduced me to this framing of different degrees of organization and I found it rather useful. Recently, I shared the framing with my son and he came up with a pretty neat metaphor that I will try to capture here.

Imagine a box of gears. All gears are of different sizes and kinds. There are spur gears, bevel gears, herringbone, and their tooth spacing is all different. It’s a boxful of random junk. We call this state disorganized: entities are disjointed and aren’t meant to fit together.

Now, let’s imagine a different box. It is also full of gears, but here, all gears are of the same kind, and they all fit. It’s still just a pile of gears, but at least they are consistent. This state of consistency is our next degree of organization. The entities fit together, but aren’t connected in any way.

If we took the gears out of that second box and built a working gear system out of them, we would achieve the next degree of organization, the state of cohesion. Here, the entities have been organized into something that actually does something — we turn one gear and all others start turning with it. It’s amazing.

But what does this gear system do? This is where the story’s final degree of organization comes. Running rigs of gears are cool, but when we build them to do something intentional — like changing the rotational speed or torque of a motor — we reach the state of coherence. In this state, the entities don’t just work together, they are doing so to fulfill some intention. The addition of intentionality is a focusing function. In the state of cohesion, we’d be perfectly fine with building a contraption that engages all the gears we have. When we seek coherence, we will likely discard gears that might fit really well, but don’t serve the purpose of intention.

We also noticed that the states aren’t necessarily a straight-line progression. Just picture a bunch of gears that barely fit, rigged to do something useful — thus skipping the consistency stage altogether.

Playing with this metaphor and developer surfaces (APIs, tools, docs, etc.) produces a handy set of examples. If my APIs are all over the place, each in different language, style, and set of dependencies, we can safely call my developer surface disorganized. Making them all line up and match in some common style/spirit turns them consistent. If I go one step further and make the APIs easy to combine and build stuff with, I’ve taken my developer surface to the state of cohesiveness. Given how rare this is in real life, it’s a reason to celebrate already. But there’s one more state. My developer surface is coherent when the developers who use it produce outcomes that align with my intentions for the surface. If I made a UI framework with the intent to enable buttery-smooth end-user interactions, but all the users see is a bloated, janky mess — my developer surface could be consistent and cohesive, but it’s definitely not coherent.

Leave a Reply