Humans have a natural tendency to organize complexity through the establishment of hierarchy. It’s an effective tool across domains and contexts.
Consider two graph diagrams. The first graph is organic, in the sense it doesn’t clearly convey any intentional structure.
The second graph is structured and hierarchical. It represents layering, flow, intentional relationships.
Software engineers might see software architecture represented in these images. Managers might see organizational structure. Data engineers see data lineage or schema relationships. A coach sees teamwork.
Our cognitive capacity is limited, as humans. The Magical Number Seven, Plus Or Minus Two described limits to human working memory, written in the 1950s. Hierarchies allow people to compartmentalize information, to group similar things together behind mental abstractions, upon which we can generalize without thinking too hard about the specifics. They provide a sense of order, even though they can over-generalize or hide information.
Hierarchy formation within groups of people is a natural instinct, even from infancy. From Harvard Business Review in 2003:
Yet the intensity with which we struggle against hierarchies only serves to highlight their durability. Even today, just about every large organization remains hierarchical. The organizations of the knowledge economy — whether loosely coupled, networked, or federalized — seem to be no more than modifications of the same basic design
This in spite of the fact that egalitarian structures, when they work, tend to produce better outcomes because the members believe more strongly about mutual benefit from cooperation.
An analog in the software world is the often-cited principle of composition over inheritance. From the wiki article:
It is more natural to build business-domain classes out of various components than trying to find commonality between them and creating a family tree. For example, an accelerator pedal and a steering wheel share very few common traits, yet both are vital components in a car.
One could take that anecdote and practically apply it to either software or organizational design.
When we talk about software abstraction, we are usually trying to map software design principles onto our innate mental hard-wiring for hierarchical clarity. Classes and interfaces, services and API specifications, OSI layers, virtualized containers versus metal cores on a machine. Object-oriented inheritance.
The end result of the abstraction is a hierarchical relationship between the abstraction’s users, customers or interfaces, and the complexity of everything hidden below it. If the abstraction is too vague, it's over-engineered and brittle. If it's too weak or un-opinionated, it doesn’t provide value.
When designing a hierarchy of any kind — people, software, taxonomies, or whatever else — the challenge is balancing the simplicity of the hierarchical abstraction against the rigidity it imposes. Striking the right balance often means specifically accounting for the edge cases via escape hatches and focusing on finding value bounded by the 80/20 rule.
