From bricolage to engineering: regularizing complexity
If one calls bricolage the necessity of borrowing one’s concepts from the text of a heritage which is more or less coherent or ruined, it must be said that every discourse is bricoleur. The engineer, whom Lévi-Strauss opposes to the bricoleur, should be the one to construct the totality of his language, syntax, and lexicon. In this sense the engineer is a myth. A subject who would supposedly be the absolute origin of his own discourse and would supposedly construct it “out of nothing,” “out of whole cloth,” would be the creator of the verbe, the verbe itself. The notion of the engineer who had supposedly broken with all forms of bricolage is therefore a theological idea; and since Lévi-Strauss tells us elsewhere that bricolage is mythopoetic, the odds are that the engineer is a myth produced by the bricoleur. From the moment that we cease to believe in such an engineer and in a discourse breaking with the received historical discourse, as soon as it is admitted that every finite discourse is bound by a certain bricolage, and that the engineer and the scientist are also species of bricoleurs then the very idea of bricolage is menaced and the difference in which it took on its meaning decomposes.
— Jacques Derrida, “Structure, Sign, and Play in the Discourse of the Human Sciences.”In The Structuralist Controversy: The Languages of Criticism and the Sciences of Man, edited by Richard Macksey and Eugenio Donato (Baltimore: Johns Hopkins University Press, 1972), pp. 255–56. Originally delivered at Johns Hopkins University in 1966.
In The Savage Mind, Claude Lévi-Strauss drew a sharp contrast between two modes of creation: the engineer and the bricoleur. The engineer designs from abstract principles, guided by blueprints and logic; the bricoleur works with what’s available—“a set of tools and materials which is always finite and heterogeneous,” as Lévi-Strauss put it. The engineer imagines new systems from first principles; the bricoleur reuses, reinterprets, and recombines. One builds from the top down; the other, from the middle outward.A close cousin is jugaad, resourceful improvisation under constraint. Its linguistic ancestry reaches into a richer vocabulary: the Oxford English Dictionary traces it through Sanskrit yogyā, contrivance, to yuj, to join or yoke—the family that also includes yukta, joined or fitting, and yukti, combination, expedient, reasoning. The philosophical resonance is not simply doing more with less. In the Caraka Saṃhitā (Sūtrasthāna 11.23–25), yukti concerns how outcomes arise from a conjunction of causes; in the Bhagavad Gītā 6.17, yukta describes measured habits and effort. These are parallels, not proof of a direct doctrinal lineage. What interests me is the thought they make available: intelligence is neither abstract order imposed on circumstances nor ingenuity released from discipline, but the capacity to make means, conditions, and purposes fit. A workaround discovers that fit once. Regularization makes it dependable without requiring its inventor to return each morning.
The financial world is messy by design. Multiple actors—portfolio managers, advisors, custodians, clients, internal systems—are all touching the same account at different times, with different versions of the truth. It’s the software equivalent of a race condition: outcomes depend on the order and timing of interactions, and those interactions are never synchronized. In that environment, pure engineers don’t thrive. They expect deterministic systems and stable interfaces, but finance is inherently asynchronous and probabilistic. Data arrives late, accounts reconcile retroactively, and exceptions are the norm, not the edge case. What looks like bad design is often just the topology of the domain itself.
That’s why fintech is hard. It demands both engineering and bricolage, and doing one too well comes at the cost of the other. Engineers build beautifully structured systems that can’t keep up with the market’s pace. Bricoleurs improvise endlessly, shipping quick fixes that pile up as technical debt. Each mindset solves for what the other breaks. Lévi-Strauss described this tension long before software existed. The bricoleur, he wrote, “speaks not only with things, but also through the medium of things”—repurposing what’s at hand, operating through constraint and improvisation. The engineer, by contrast, starts from first principles, chasing universality and internal coherence. Both forms of intelligence are valid, but neither alone can sustain a system that must evolve daily and still reconcile precisely to the cent.
That’s where regularization comes in—a concept I first learned from Mike Purewal, and one I’ve since recommended to every colleague. Borrowed from machine learning, it means penalizing complexity: adding deliberate constraints so the model doesn’t overfit to noise. Applied to operations, regularization becomes the discipline of constrained flexibility—a way to reconcile the engineer’s need for structure with the bricoleur’s instinct for improvisation. It’s not about limiting intelligence; it’s about shaping it so it generalizes.
David Today at 17:20 It doesn’t appear to stem from a single source—more likely a combination of (1) general strain on core infrastructure, (2) data delays, and (3) human errors. My main takeaway is that the complexity of daily operations demands stronger systemization—by “systemization,” I mean tighter regularizationMike Purewal, Regularization for Real Life that allows us to trade nearly all accounts on nearly all days without human intervention (and without leaving any account behind for too long), rather than relying on daily expert swarms to manually restore the system to an ideal state in real time.
I’m noticing a general hesitation—conscious or not—to “close” the system, driven by concern that it won’t be able to handle real-world imperfections, which are practically unbounded. But I think we need to draw a clearer line: be more disciplined about what the machine handles autonomously, and what it can achieve with runtime adjustments. Blurring the two is what’s holding back our progress.David Wood, post-mortem note (excerpt) after missing internal trading target
Systemization, in this sense, isn’t about eliminating human judgment. It’s about drawing a clean boundary around it—designing processes that can run autonomously across almost all accounts, almost all days, without constant expert intervention. The goal isn’t perfection; it’s bounded imperfection. The constraint is what creates stability. Fintech systems don’t fail because people aren’t smart enough. They fail because complexity accumulates faster than control. Regularization—imposed consciously through process, code, and organizational design—is what turns bricolage into engineering. It’s what allows creativity to scale without collapsing under its own weight. Systemization through regularization doesn’t mean freezing change—it means defining the operating envelope clearly enough that the machine can keep running, while we focus human energy on the things that still require judgment.
Some practical takeaways:
Explicit regularization schemes. Engineers need to articulate the constraints under which their systems operate—what’s guaranteed, what’s probabilistic, what’s out of scope. That’s not a bureaucratic exercise; it’s what separates a robust design from a clever patch.Clarification. It is crucial to distinguish explicit regularization (upfront articulation of constraints and boundaries) from retroactive rationalization. If a system fails due to an oversight of a necessary corner case, that is a miss. Retroactive regularization is not a thing. Applying retroactive rationalization to cover a mistake is one of the fastest ways to lose credibility.
Reduce exception leakage. Code shouldn’t raise errors unless something truly violates its contract. Every unnecessary alert or “manual check required” leaks engineering uncertainty into operations. Containment is discipline.
Favor continuity over perfection. In finance, the show must go on. Trading systems must transact even under partial degradation. Strive for a narrow band of optimality rather than a binary of “works” vs. “breaks.” A predictable imperfection is better than a fragile ideal.
Engineer for partial truths. In finance, data is never fully consistent—positions update late, custodians disagree, prices roll in asynchronously. Systems should be designed to transact and reconcile under partial information, not wait for a perfect state that never arrives.
Design with slack, not buffer. A buffer absorbs load temporarily; slack absorbs disorder. Build time and tolerance into processes—for delayed data, retries, or temporary mismatches—without cascading failures.
Regularization enables creative destruction. As Paul Kwon reminded me, there’s a natural but unhealthy fixation on the status quo—even when maintaining it consumes excessive effort. That’s a sign the system is under-regularized. When regularization is strong, it’s safe to let old mechanisms fail and be replaced. The goal isn’t endless preservation; it’s controlled evolution. Constraining complexity creates the conditions for renewal, because the cost of change stays bounded.