From bricolage to engineering: regularizing complexity
Nov 7, 2025
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.
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.