For over fifty years, object-oriented programming (OOP) has been the dominant way to think about building software. The core idea sounds intuitive: software should mirror reality. If your app deals with users, orders, and products, then you should have User, Order, and Product classes — each bundling the data and the behavior that "belongs" to that thing. Daniel Jackson, an MIT professor and longtime software design researcher, argues in this paper that this foundational assumption is actually wrong — and that decades of pain in software engineering can be traced back to it.

The problem with objects. Jackson's central complaint is that real-world functionality almost never lives cleanly inside one object. Consider a "checkout" feature in an e-commerce app. Which class owns it? The Cart? The Order? The Payment? The User? In practice, the logic gets smeared across all of them, with each object holding a fragment. This is what he calls fragmentation: a single coherent behavior gets shattered into pieces scattered across the codebase, and you have to mentally reassemble it every time you want to understand or change it.

The decades of patches. Jackson points out that much of software engineering's history since OOP has been an attempt to paper over this exact problem. Design patterns (Visitor, Strategy, Observer), aspect-oriented programming, dependency injection frameworks, domain-driven design's "bounded contexts" — all of these, he argues, are workarounds for the fact that objects don't actually carve software at its natural joints.

The alternative: concepts. Jackson proposes organizing software not around things (objects) but around concepts — independent units of user-facing functionality. A concept like "reservation," "upvoting," or "trash bin" is self-contained: it has its own state, its own actions, and its own purpose, and you can understand it without knowing about the rest of the system. Concepts are then composed together (he calls this "synchronization") to build full applications. Crucially, the same concept (say, "comments") can be reused across wildly different apps because it isn't tangled with any particular domain object.

The paper is partly a postmortem of OOP's limitations and partly a manifesto for what comes next. Jackson has been developing "concept design" for years; this piece is his clearest argument for why the industry should move on from the object-first mindset entirely.