Skip to content

Interlude: The Bricolage of Systems

The Two Modes of Innovation

In his seminal work The Savage Mind (1962), anthropologist Claude Lévi-Strauss distinguished between two fundamental modes of human thought: the Engineer and the Bricoleur.

The Engineer defines a project and creates specific tools to execute it. Their universe is theoretically open; they seek to expand knowledge by creating new materials, new methods, new infrastructure, and new capabilities from first principles. This is the idealized model of modern science and industrial manufacturing—specialized, precise, optimized, and often siloed.

The Bricoleur (or "tinkerer"), by contrast, works with "materials at hand." They confront a problem by looking at a finite collection of existing tools and scraps—leftovers from previous projects—and asking: "What can this signify? How can I rearrange these existing pieces to solve my current problem?" The Bricoleur does not wait for the perfect tool; they interrogate the available materials to discover what they could do.

The Encyclopedia as a Toolkit

In this encyclopedia, bricolage means solving by recombining stable abstractions under constraints, rather than inventing new primitives. For that reason, the Encyclopedia of Abstractions is fundamentally a resource for the Bricoleur.

In a complex, interconnected world, we rarely have the luxury of being pure Engineers. We cannot invent a new branch of mathematics for every business problem, nor can we derive a new physics for every software architecture. Instead, we must operate as Bricoleurs. We must look at the "materials at hand"—the finite set of universal patterns—and ask how they can be recombined to solve the novel problems before us.

This distinction maps directly to the taxonomy of this encyclopedia:

  • Prime Abstractions are the Bricoleur's Materials. These are the universal "scraps" found in every system—Feedback, Superposition, Hierarchy, Entropy. They are deliberately curated and defined to be robust, portable, and recombinable across contexts. They are the wood and stone of the intellectual world.

  • Domain-Specific Abstractions are the Engineer's Instruments. Concepts like "Double-Entry Bookkeeping" or "TCP/IP Handshake" are specialized tools. They are incredibly efficient for their intended purpose but brittle when removed from their context.

  • Ephemeral Abstractions are Temporary Jigs. These are the ad-hoc patterns we notice in a specific project. They are the "jigs" the Bricoleur builds to hold things in place for a moment. Sometimes, if a jig proves useful enough, it is refined and promoted into a Prime Abstraction.

Optimizing for Viability

There is a tendency in modern thought to view Bricolage as "second-best"—a clumsy fallback when "real" engineering isn't possible. This is a mistake.

Engineering optimizes for optimality under assumptions. It works best when requirements are stable, stakes justify the cost of custom tooling, and the environment is controlled. Bricolage optimizes for viability under constraints. It works best when ambiguity is high, timelines are short, resources are fixed, and the solution must live within a legacy ecosystem.

In complex sociotechnical systems—where assumptions rarely hold and the environment is never static—viability usually beats optimality. The Bricoleur wins not because they are smarter, but because they are faster and more resilient. They build with what is, rather than what ought to be.

"Good to Think With"

Lévi-Strauss famously observed that totemic animals (like the Eagle or the Bear) were chosen by clans not because they were "good to eat," but because they were "good to think with." They provided a concrete structure to classify the chaotic social world.

The abstractions in this volume are the totems of the systems age. To be "good to think with" in a modern context means an abstraction satisfies five criteria:

  1. Compressive: It reduces a complex phenomenon into a manageable handle.

  2. Portable: It survives transfer from one domain to another without losing meaning.

  3. Composable: It can be "snapped together" with other abstractions to form larger models.

  4. Diagnostic: It helps you see why a system is failing (e.g., "This is an oscillation caused by undamped feedback").

  5. Generative: It suggests interventions (e.g., "If it's an oscillation, I need Damping").

A Worked Example: Bricolage in Incident Response

Consider a Site Reliability Engineer (SRE) facing a cascading failure in a distributed database. The system is overloaded, latency is spiking, and customers are angry.

The Constraints: The SRE cannot write and deploy new code (The Engineer's method) because the deployment pipeline is too slow and the risk of new bugs is too high. The Materials at Hand: The SRE looks at the dashboard and identifies three Prime Abstractions currently at play: Flow, Capacity Constraints, and Coupling.

The Recombination: The SRE acts as a Bricoleur. They do not invent a new database. They assemble an intervention using standard architectural patterns:

  1. Boundary: They activate a "Circuit Breaker" to sever the connection between the web tier and the database.

  2. Sampling: They implement "Load Shedding" (a form of Sampling) to drop 50% of incoming traffic.

  3. Feedback: They watch the latency metrics to see if the system stabilizes.

The Result: The system recovers. The solution was not "optimal"—users were dropped. But it was viable. It was constructed in minutes using universal structural concepts (shedding, breaking, observing) applied to a specific technological emergency. 

The SRE didn't "memorize incident response"; they recognized the structural signature (flow/capacity/coupling) and assembled a response.

The Bricoleur's Loop

How does one practice this? The method of the Bricoleur can be formalized into a five-step loop:

  1. Name the Situation: What is the phenomenon? (e.g., "The system is oscillating.")

  2. Invariants: What must remain true even if we degrade service? (e.g., "Data integrity cannot be compromised.") 

  3. Choose Boundaries: What is in scope? What can I touch? (e.g., "I can change configuration, but I cannot change code.")

  4. Select Abstractions: Pick 3-5 Prime Abstractions from your mental inventory that fit the structural signature. (e.g., "Feedback," "Buffer," "Rate Limit.")

  5. Compose an Intervention: Assemble these abstractions into a Solution Archetype. Implement it, and observe the result.

The Trap of Metaphor

A caution is necessary. Bricolage is rigorous; it is not poetic license.

There are two failure modes where abstraction degrades into mere metaphor:

  1. Cargo Culting: Using the word "Feedback Loop" as a vibe rather than a mechanism. If you cannot identify the sensor, the comparator, the actuator, and the measured signal, you do not have a feedback loop; you have a complaint.

  2. Overfitting: Forcing a familiar abstraction onto a mismatched situation. If you treat every problem as a "Nail," you will misuse the "Hammer" abstraction.

The rule of thumb is this: If you cannot name the mechanism and the measurement, you do not yet have the abstraction.

Bridge to Action

This interlude serves as the pivot point of the Encyclopedia.

  • Inventory—the nouns of our language.

  • Methodology—the verbs.

The following section provides a detailed Inventory along with Solution Archetypes that catalog the most common successful recombinations of these materials. They are not rigid prescriptions; they are templates for composition. They are the proven recipes that previous Bricoleurs have discovered while tinkering with the recurring structures that govern complex systems.

Next → Definitions