Speculative Generality

Building for future requirements that may never come.

“Oh, I think we need this kind of thing someday.” – Fowler & Beck

Signs of Use (Symptoms)

  • Abstract classes/interfaces with only one implementation.
  • Parameters or hooks that are never used (“for future extensibility”).
  • Framework code for features that don’t exist.

Why it is bad (Consequences)

  • Complexity: Code is harder to understand.
  • Maintenance: You maintain code for non-existent features.

Why it happens (Root Cause)

Developers trying to “future-proof” or “design for extensibility” prematurely.

When it might be okay (Exceptions)

  • Designing a public API/library where future compatibility is critical.

Explanation

Problem

You create an IPaymentProcessor interface with complex plugin hooks. Only StripeProcessor ever implements it.

The Flaw

YAGNI. You built for flexibility no one asked for.

Real world analogy

Building a 10-lane highway for a small village.

Refactoring Solution

  • Collapse Hierarchy: Merge unnecessary abstractions.
  • Inline Class / Remove Method: Delete unused extensibility points.

Pros and Cons (of the Antipattern)

Pros (Why people do it) Cons (The price you pay)
  • “Future-proof”
    		•
  • Wasted effort
  • Complexity
    		•

    Comparison

    • Related Antipatterns: Lazy Class, Dead Code.
    • Related Principles: YAGNI.

    Code example

    Typescript

    Bad (The Antipattern)

    Good (The Fix)