Worse is better and the right thing

May 31, 2026

It takes a tough man to make a tender chicken

The big complex system scenario goes like this:

First, the right thing needs to be designed. Then its implementation needs to be designed. Finally it is implemented. Because it is the right thing, it has nearly 100% of desired functionality, and implementation simplicity was never a concern so it takes a long time to implement. It is large and complex. It requires complex tools to use properly. The last 20% takes 80% of the effort, and so the right thing takes a long time to get out, and it only runs satisfactorily on the most sophisticated hardware.

The diamond-like jewel scenario goes like this:

The right thing takes forever to design, but it is quite small at every point along the way. To implement it to run fast is either impossible or beyond the capabilities of most implementors.

Richard P. Gabriel’s Worse Is Better essays describe a design argument that is easy to caricature because it sounds like a defense of bad work. It is not. It is a theory of survival under constraint.

Gabriel contrasts two styles. The MIT, or “right thing,” tradition begins from the ideal form of the system. It values correctness, consistency, completeness, and simplicity, with correctness and consistency treated almost as moral obligations. The New Jersey, or “worse is better,” tradition begins somewhere else: with the implementation. The system should be simple enough to build, simple enough to port, simple enough to understand, and simple enough to survive contact with the world. If that means the interface is less elegant, the edge cases less hidden, or the first version less complete, so be it.

The provocation is that the apparently worse system may have better evolutionary properties. A small system can spread before a more complete one is finished. Once it spreads, it changes the environment around it. Users adapt to it. Programmers learn its idioms. Tooling accumulates. Institutions build around it. Compatibility becomes a force. What began as a compromise becomes infrastructure.

That is Gabriel’s point about Unix, C, and later C++. These systems were not always the most coherent, complete, or beautiful. But they were simple enough, fast enough, portable enough, and useful enough to become the substrate on which other things depended. Their imperfections did not prevent adoption; in some cases, the very compromises that made them inelegant made them transmissible.

What do you expect from an OS designed and implemented in New Jersey?

The danger is to mistake this for permission. “Worse is better” is not a license to aim low. Compromise is often unavoidable; intentional mediocrity is not a design philosophy. Gabriel’s later worry, in “Worse Is Better Is Worse,” is that a descriptive claim about how systems win can harden into a normative excuse for sloppiness. The fact that some imperfect systems survive does not mean imperfection is the goal.

The more useful reading is operational. Worse-is-better is a warning about the conditions under which systems actually become real. They win through adoption, habitability, portability, and the ability to improve under use. A beautiful system that never survives contact with the world is not obviously better than an imperfect one that can grow. But an imperfect system that cannot be regularized is just deferred failure.See From Bricolage to Engineering: Regularizing Complexity. Brandon Rhodes’s useful formulation is that software design complexity should be managed by keeping effects at the edges and logic in the center. In The Clean Architecture in Python, he argues against merely burying complexity inside subroutines—especially I/O complexity—and instead emphasizes decoupling: external effects like HTTP calls, databases, files, and APIs should be separated from the core logic that transforms data and expresses the program’s real rules. The result is close to “functional core, imperative shell”: a small, testable center of pure or nearly pure computation, surrounded by a thinner layer that performs messy interaction with the outside world. In the terms here, Rhodes is describing one practical technique for regularization: not eliminating mess, but deciding where it is allowed to live.

This is where the argument begins to matter for fintech. Financial systems do not operate in a clean, synchronized, fully specified world. They operate across late data, changed vendor formats, drifting conventions, operational exceptions, and edge cases the world invents after deployment. The question is not whether the first version will be incomplete. It will be. The question is whether the incompleteness is explicit enough to be managed.

That distinction matters because the alternative to an incomplete system is not usually a complete and correct one. It is often a system that returns a number for everyone, including cases it does not understand. That feels better because it fails less visibly. But it converts a known boundary into an unknown misstatement. A defined implementation error is embarrassing, but it is honest. A silently wrong number enters reports, drives decisions, passes through downstream systems, and acquires the authority of computation.

So worse-is-better, in this setting, is not a defense of lower correctness. It is a defense of bounded (in)correctness. The system should be simple enough that the people who own it can understand where it is right, where it is incomplete, and where it must refuse to answer. In a dynamic domain, correctness depends as much on knowing when not to calculate as on calculating correctly inside the contract.

The same pattern shows up in platform customization. Too much openness often looks like respect for local practice, but at scale it becomes another way for disorder to hide. The platform has to decide where the shared substrate belongs, which defaults should be made easy, and which deviations require articulation. Freedom above the substrate requires discipline beneath it.See How Much Customization Should a Financial Platform Offer?

Seen this way, worse-is-better is not the opposite of engineering. It is one account of how engineering often begins. The first version may be partial, local, and imperfect because the domain itself is partial, local, and imperfect. The discipline comes later, but not accidentally: the improvisation has to be regularized before it hardens into permanent disorder.

The real comparison, then, is not between good design and bad design. It is between two ways of managing complexity over time. The MIT approach asks what the system should be if we could get it right. Worse-is-better asks what kind of system can survive long enough to become right.

Why fintech votes for the “right thing” — and why the vote is a trap

It doesn’t matter if the interface is ugly, because the user’s just gonna have to deal with it.

If you come to software from a quant seat, or you have spent a career managing rather than building, the right thing reads as obviously correct. Its four virtues translate cleanly into a language the room already speaks. Correctness is fiduciary duty. Consistency is operational risk. Completeness is coverage—the cases you are paid to have anticipated. Each has a constituency. The risk officer will not let consistency slip. Compliance will not let completeness slip. And no one will go on record trading away correctness.

Simplicity has no such constituency.The hidden simplicity of implementation, not the visible simplicity of interface. The interface may become uglier precisely because the implementation is being kept small enough to understand, port, and maintain. No one is paid for the abstraction not added, the case deferred, the line not written.

The bias is not wrong about the virtues. They are the right virtues. It is wrong about time. It treats correctness, consistency, and completeness as properties a system has on the day it ships, rather than properties a system must keep.

A system is not correct once. It is kept correct across late data, changed vendor formats, drifting conventions, operational exceptions, and edge cases the world invents after you deploy. The capacity to keep a system correct depends on whether the people who own it can understand it, change it, and reason about why it is shaped the way it is. That capacity is simplicity.

There is another trap inside the word correctness. In finance, the alternative to an incomplete system is not usually a complete and correct one. It is often a system that returns a number for everyone, including cases it does not really understand.

That feels better politically because it fails less visibly. There are fewer explicit implementation errors, fewer blocked workflows, fewer users told that the system cannot yet handle their case. But the cost is that some users sometimes get a number that is simply wrong, and you may not know which users or when. The failure has not been eliminated. It has been converted from a known boundary into an unknown misstatement.

That is usually the worse fiduciary trade. It says: this case is outside the system’s current contract. It can be counted, routed, reconciled, prioritized, and eventually regularized. A silently wrong number is worse. It enters reports, drives decisions, passes through downstream systems, and acquires the authority of computation. By the time anyone discovers it, the system has already taught the organization to trust it.

So the real correctness question is not whether the system always produces an answer. It is whether the system knows when it should not. In a dynamic domain, correctness depends as much on refusing to calculate outside the contract as on calculating correctly inside it. The responsible system is not the one that pretends to cover every case. It is the one that makes its boundaries explicit, fails loudly at those boundaries, and creates a path by which today’s implementation error can become tomorrow’s supported case.

In a static frame, simplicity loses to the other three. In the frame that actually governs financial systems—years of change under load—simplicity is what carries the other virtues forward. It is not opposed to correctness. Over time, it is the vehicle for it.

This is why the right-thing instinct fails not only as an engineering principle, but as an incentive structure.

You want engineers to own engineering. That is the core issue. A product is not separable from the engineering that delivers it: the architecture, operational model, failure modes, and constraints are all part of what the product actually is. In weak organizations, “product” becomes the language of desire while “engineering” becomes the language of delivery, as if the first could be specified independently of the second. But a product that cannot be delivered coherently, operated safely, repaired under pressure, or changed without collapse is not a product in any serious sense. It is a wish attached to a codebase. This is Conway’s law in organizational form: the system will eventually reflect the communication structure of the people who build it. If product owns desire, engineering owns implementation, operations owns consequence, and leadership owns narrative, the software will reproduce those separations as interfaces, handoffs, gaps, and failure modes. Ownership means someone can hold the architecture in their head, reason from first principles about each part, and defend or revise that reasoning as the domain becomes clearer. A simple architecture is ownable. A maximal one, handed down as a set of obligations to satisfy, is not. Simplicity is therefore not a nicety; it is the precondition for accountable engineering judgment. Without strong engineering leadership that owns the system as part of the product, the organization may keep shipping features, but it will not have a lasting working product.

When completeness and consistency are imposed as moral requirements before anyone understands the domain, the engineer stops reasoning and starts complying. They build to the specification, not to a model they hold. The work becomes defensive. Every case is represented because no one wants to be accused of having missed it. Every exception becomes architecture. Every ambiguity becomes another branch.

Then reality arrives, partial and inconsistent and late, as it always does in finance. The over-specified system cannot bend, so it is patched. The patches accrete. No single person can still reason about the whole. Correctness begins to rot silently, not because no one cares about it, but because no one can see all of it at once.

I have watched this happen more than once: a senior engineer sets out to do the right thing, and the result is a system so committed to its own completeness that it has to be rescued—rewritten, simplified, redesigned from first principles. Which is the simple thing that should have been built first. What was the point of the detour?

The fiduciary argument, taken seriously, runs the other way. Your duty is not to the most fully specified system on day one. It is to a system that stays correct, auditable, and adaptable as the world it models keeps moving. That is a habitability problem before it is a completeness problem.

The most responsible thing you can ship is something simple enough that the people who own it can keep it right, and structured so that each compromise made under pressure becomes a place to regularize later rather than a place for disorder to hide.

Worse-is-better, in fintech, is not lower standards. It is the recognition that in a domain this dynamic, simplicity is the precondition for everything else you claim to care about.

The abbot sweeps the floor

If simplicity is what carries the other three virtues forward, then the New Jersey program rests on the one virtue no one in the room is paid to defend. That is not mainly a technical problem. It is an organizational one. The forces that erode simplicity are the same forces I described in Good Companies and Good-Looking Companies: the firm that has learned to produce the signs of building without submitting itself to the brutality of building something. Simplicity is not eroded only by bad engineers. It is eroded by ordinary institutional self-protection. Start with Conway’s law, because it is usually treated as engineering folklore with an organizational footnote. It is the reverse. It is an organizational law that writes itself into software. A system comes to mirror the communication structure of the people who build it. If responsibility is split before the architecture is settled, the splits become interfaces, handoffs, and seams whether or not the domain wanted them there.

And responsibility is always split. Product asks for optionality, because optionality is what product is rewarded for. Engineering protects itself with abstractions, because abstraction buys room to be wrong later. Operations builds runbooks around consequences it did not choose. Leadership asks for legible progress, because legibility is what it can report upward. Each move is defensible in isolation. Together they produce a system no one owns end to end: four self-protections assembled into architecture.The maneuver, if you have the authority to attempt it, is to run Conway in reverse: decide the architecture you want, then draw the team boundaries that would produce it, rather than letting the organization’s accidents harden into the system’s seams. Most organizations never get to do this, because the boundaries were drawn by hiring order and politics before anyone asked what the system should be.

This is where simplicity becomes politically dangerous. A complex system distributes blame. When something breaks, the failure lives in the seams between owners, and no single person can be made to answer for it. A simple system removes the seams, and with them the hiding places. It forces priority, because you cannot keep every feature. It forces refusal, because someone has to say no. It forces architectural judgment, because the shape is visible. And it forces named accountability, because once the system is small enough to hold in one head, the question whose head? has an answer.

This is why organizations so often prefer a maximal system that looks serious to a simple system someone actually has to own. The maximal system is more comfortable precisely because it is unownable. Complexity is a place to stand when the music stops.

The selection problem makes this worse, and it begins at the top. Most founders do not share a domain. Unless every founder is an engineer—and they almost never are—someone has to hire engineering leadership, and the person doing the hiring cannot fully evaluate the thing he is hiring for. So he selects on the dimension he can read.

It is easier to recognize, and easier to work with, an engineering leader who speaks fluently about the business of engineering—roadmaps, velocity, headcount, risk, the four virtues rendered as governance—than one who is merely, inconveniently, in love with engineering itself. The right-thing framing is seductive here for exactly the reason given earlier: it translates without friction into the language the room already speaks. Correctness is fiduciary duty. Consistency is operational risk. Completeness is coverage. Each constituency nods, and the candidate sounds like the safe hire.

He is not. He is the legible hire, which is a different thing, and the distance between the two is where simplicity goes to die.The business-of-engineering leader is the value-extractor’s natural habitat inside a technical organization. He optimizes the documented surface—the roadmap, the dashboard, the deck—because that is what can be priced, and he cannot see the slow, tacit relation between a mind and a system it has had to understand under pressure. He confuses the surface of the work with the work, and the confusion is invisible until reality arrives.

The way out is not to demand that founders become engineers, or that engineers become quants. It is to demand cross-domain literacy in place of cross-domain expertise. If you found in the tech space, you do not need to be a proficient coder, a Cisco networking expert, or a cloud engineer. You do need a working mental model of the system: how the major parts function, where they intersect, what constrains them, what breaks when. The obligation is symmetric. If your domain is finance, you do not need a PhD in a quantitative discipline, but you are bound to strive to be a good investor: to understand the offering well enough to diagnose and solve most of what the customer actually needs. Domain attachment is a dignity, because it gives a person something real to answer to. But attachment without literacy across the boundary is exactly how Conway’s seams become permanent. Someone has to be able to see the whole, or the whole belongs to no one.

Which returns us to ownership, and to the difference between claiming it and bearing it. Everyone wants to be called an owner. Almost no one wants what ownership costs: the political risk of saying no, the responsibility to clean up the f—up after a yes turns out to have been wrong, the daily drudgery of reviewing and approving pull requests, the angry client conversations when the system’s limits become visible, and the cognitive burden of holding the whole in your head while everyone else holds only their piece. So ownership becomes another title—aspiration rather than responsibility—and the system evolves aimlessly. It accretes well-meaning pull requests from young contributors, each locally reasonable, none of them accountable for the long-term shape of the whole.

Core infrastructure needs a benevolent dictator.I have called the stop on this a few years ago. Every PR to our core rebalancer stack is reviewed and personally approved by me, and I see myself first as a quant, not an engineer. It is not comfortable and it does not scale gracefully, but I have not found another way to advocate for simplicity that actually holds. Not every repo. Federate the periphery; centralize the core. The same logic as platform customization: freedom above the shared substrate, discipline beneath it. A dictator over the whole surface is just a bottleneck. A dictator over the load-bearing core is a spine. Not a manager. An ascetic abbot: someone who knows the temple inside out and sweeps its floor every day. The sweeping is the point. You earn the authority to refuse a change by being the person who lives with the consequences of every change you have already allowed. Authority that is not paid for in consequence is just the title problem again, wearing a reviewer’s badge.

The danger of the abbot is that he becomes the thing he was protecting against: the single point of failure, the hoarder of architectural knowledge, the bottleneck whose absence stalls the temple. A dictator who only vetoes has built a bus factor of one. So the abbot’s deeper job is not veto. It is transmission.

He has to cultivate taste in others until the veto becomes mostly unnecessary. He has to teach the embodied, judgment-laden sense of the system that cannot be compressed into a rule or a linter. This is apprenticeship, not gatekeeping. It is also the only exit, because the dictator is sacrificial architecture in the social sense: a stage the system passes through on its way to a form that can govern itself.Agentic coding sharpens this. When the marginal cost of producing more code falls toward zero, the discipline of not producing it has to rise to compensate. Code is a liability; the shared, owned understanding of the code is the asset. A model can generate the abstraction not needed and the case not asked for faster than any human reviewer can refuse them. A linter cannot want the system to stay simple. Only a person who loves it can. See §12 of Reflections on Financial Advisory and Portfolio Management.

The durable form of this is the workshop, and the workshop has one non-negotiable condition: the people who build the system must be customers of their own work. That is the whole argument compressed into a rule.

You cannot grow a community of artisans who self-enforce simplicity—who refuse complexity not because a reviewer scares them, but because simple systems work and are easier to fix—unless they live inside the thing they build. Hand the reconciliation system to engineers who never operate it, who never sit through the daily breaks, who never have to explain to an angry client why a number was wrong, and you will not get a functioning reconciliation system. You will get a beautiful object that fails its first honest contact with the world.

The relationship that makes care possible is built only one way. You use what you have to get the job done. You eat and kill and sleep in the ditches with the system. And the love of it—the attachment that eventually enforces simplicity better than any dictator can—grows out of having survived it together.

This is the workshop from Good Companies in its operating form: not a romantic room of tools, but the community in which thought is made answerable to a resistant object before it is converted into status, title, or theater.

So the New Jersey model, taken seriously, asks far more than its caricature suggests. It does not ask you to ship junk quickly. It asks you to keep the system simple enough to remain ownable, to find the person willing to bear the real cost of owning it, and then to dissolve that dependence into a community of people attached enough to the work to keep it simple without being told.

Simplicity is not a technical preference you can adopt by decree. It is an organizational achievement, won against every incentive that rewards looking busy over being answerable. The reason worse-is-better is so often invoked and so rarely practiced is that the hard part was never the code. It was finding people who would sweep the floor.