TS
Sign In
Knowledge Base
Detailed Notes||7m 5s

Casey Muratori on Crappy OOP Models

https://www.youtube.com/watch?v=n4pioKPQpz0

Here are detailed notes from the transcript:

Detailed Notes: Critique of Object-Oriented Programming and Library Design

Main Topics Discussed:

  1. Critique of Object-Oriented Programming (OOP): The speaker argues vehemently against traditional OOP concepts, particularly the coupling of methods and data in "objects."
  2. API Boundaries as the "Good Part" of OOP: The speaker redefines the useful aspect often attributed to OOP as simply designing effective API (Application Programming Interface) boundaries.
  3. Challenges of Library Design, specifically for Character Animation: Contrasting the complexity of character animation libraries with simpler ones like video codecs.
  4. Case Study: "Granny" Product and its Control System: A specific software product (Granny, implied by context) is used as an example to illustrate the negative consequences of an object-oriented design approach.
  5. Software Legacy and Maintenance: The long tail of software products and how they persist even after becoming obsolete.
  6. Learning Experience: The speaker's personal growth as a programmer influenced by these design challenges.

Key Points and Arguments:

  • OOP is Fundamentally Flawed (except for API boundaries):
    • The only sensible interpretation of OOP is as "API boundaries."
    • The core OOP concept of "associating a method with data" (i.e., objects) is "always bad" and "always wrong."
    • It leads to complex, unmanageable code and makes programs less useful.
  • API Boundaries are the Key to Good Design:
    • Systems need to be broken apart due to Conway's Law or cognitive limitations.
    • The goal is to define the "right primitives" that operate across these boundaries.
    • The ability to substitute components, often cited as an OOP benefit, is actually a benefit of well-designed API boundaries, not objects.
    • Good API design has existed "forever" in libraries and components, without needing the "object" label.
  • Character Animation is a Difficult Library Design Problem:
    • Unlike video (which expects simple color planes), character animation requires deep integration (e.g., IK adjustment, hand position tracking).
    • It's a much harder problem for the library interface layer due to this tight integration, even if the underlying implementation (like video codecs) can be technically complex.
  • "Granny" Product's Design Flaw (The Control System):
    • Most of the "Granny" product's code was designed "correctly" (implying a non-OOP approach, though not explicitly stated as such for the good parts), but the "control system" was "really bad."
    • The control system was "still sort of object-oriented," making it opaque to users ("you didn't really know exactly how things were being done under the hood").
    • It featured a centralized mechanism to "update the time" and "redo the animation for you," which the speaker calls a "terrible idea, absolutely awful."
  • The Critical Bug Incident:
    • The flawed control system was the only source of a "really bad bug" shipped to end-users.
    • A memory-constrained Xbox user requested a feature to "recycle" control structures (to save memory).
    • The speaker added a "secret part" quickly, without proper testing, which contained the "nastiest bug we ever had."
    • Argument: This feature request and the resulting bug would never have occurred if the system had been designed correctly in the first place, allowing "individual micromanagement" of updates instead of relying on the "crappy object-oriented model."
  • Modern OOP Misconception:
    • Modern teaching defines objects as "small things where methods and data are coupled and the data is tiny."
    • The speaker argues that coupling methods and data is only appropriate when the data is "big," encompassing "hundreds of structs," not just one.

Important Facts or Data Mentioned:

  • Collaborator: Jeff Roberts, who worked with the speaker on the library design.
  • Product: Implied to be "Granny" (referred to by "Granny today" and the context of character animation libraries from Rad Game Tools).
  • Comparison Technologies: Video codecs, Cobol (for legacy software comparison), Unreal Engine (as the modern alternative for character animation).
  • Target Platform: Xbox (memory-constrained, leading to the specific bug scenario).
  • Employer: Rad (Rad Game Tools, inferred), where the speaker had significant learning experiences.

Conclusions or Recommendations:

  • Avoid Object-Oriented Programming: "Just never do it."
  • Focus on API Boundaries: The truly valuable aspect of software design is creating clear, functional API boundaries for libraries and components.
  • Design for Micromanagement: Systems should be designed in a way that allows fine-grained control and understanding of underlying processes, rather than opaque, centralized "object-oriented" systems.
  • Prioritize Correct Design Over Quick Fixes: Rush jobs, especially for features necessitated by poor design, are prone to introducing severe bugs and should be avoided.
  • Re-evaluate OOP Definitions: Modern understanding of objects is too small-scale; true "coupling" should involve much larger data structures.
  • Value Learning from Experience: The speaker emphasizes that this experience was "the most I've ever learned anywhere" and crucial for their development as a programmer.
Generated with Tapescript
7f0104f - 03/02/2026