Ideas from "A Philosophy of Software Design"

Overall reception of “A Philosophy of Software Design”

• Many commenters find it one of the best practical books on software design, especially around modularity, “deep modules,” and thinking explicitly about complexity.
• Others consider it shallow or obvious, or say it covers only “low‑hanging fruit” and skips the hardest design problems (e.g., large, dynamic systems like game engines).
• Several note that you only really “get” it after some real‑world experience; junior devs may benefit but also risk over‑applying rules.

Functional programming (FP) vs the book

• FP‑oriented readers criticize the book for barely addressing purity, mutation, and separation of IO from logic.
• They argue FP (or “functional core / imperative shell”) gives formal, concrete tools for reducing complexity that should be central to any “philosophy of design.”
• Others reply that useful design philosophies need not be formally complete, and that a simpler, more accessible treatment may be more effective for most practitioners.
• Some see FP evangelism itself as quasi‑religious; there’s pushback against the idea that non‑FP developers are “unqualified” to talk about complexity.

Deep modules, APIs, and abstraction size

• A major praised idea: modules should have small, simple public interfaces but “deep” implementations that hide substantial complexity.
• Examples like Unix file IO and garbage collectors are debated: some see them as quintessential deep modules; others argue their true “interface” is large and cross‑cutting, so the example is misleading.
• Several like the guideline of narrowing public APIs and being less dogmatic about short methods; others worry about over‑abstraction (e.g., excessive service classes).

Small methods, Clean Code, and incidental complexity

• There’s substantial criticism of “Clean Code”–style rules (e.g., very short methods, many tiny classes) for leading to fragmented, hard‑to‑navigate code and lifted state.
• Others defend those books as useful for beginners to develop an aesthetic sense and awareness of maintainability, but agree rules must not be followed mechanically.

Examples, testing, and business logic

• Some feel the book’s or article’s examples (e.g., discount services) are oversimplified or even bad: they may mix distinct business concepts (shipping vs order discounts) or introduce unnecessary abstraction.
• Others argue the refactorings improve testability (via injected services and fakes) and demonstrate how to centralize logic as complexity grows.
• Several emphasize that “it depends”: duplication can be acceptable early (WET—write everything twice) until real reuse patterns and divergent requirements emerge.