Anti-Patterns and Pattern Abuse

There's a peculiar disease that afflicts software developers after they've learned design patterns. It manifests as an irresistible urge to use them—not because the problem demands a pattern, but because the developer has a pattern looking for a problem.

This is Pattern for Pattern's Sake: the application of design patterns as an end in themselves, divorced from the genuine engineering needs they're meant to serve. It transforms design patterns from problem-solving tools into ritualistic complexity, applied to demonstrate knowledge rather than solve problems.

Pattern worship isn't about bad developers—it's about good developers with miscalibrated instincts. Understanding the psychology helps us recognize and correct this tendency in ourselves.

The Belief System Behind Pattern Worship

Pattern worship rests on several implicit beliefs, each superficially reasonable but ultimately misguided:

'Good code uses patterns.'

This inverts the actual relationship. Patterns are present in good code when they solve problems. The presence of patterns isn't an indicator of quality; the appropriate solving of problems is. Code without patterns that solves its problems elegantly is better than code with patterns that creates complexity.

'Patterns are best practices.'

Patterns are contextual practices. A pattern that's essential in one context is overhead in another. Factory Method is a best practice when you have polymorphic object creation; it's ceremony when you construct one type. 'Best practice' without context is meaningless.

'Simple code is junior code.'

This inverts years of hard-won wisdom. Simple code is expert code. The expert knows when to use patterns and when to refrain. The junior developer either knows no patterns (writing accidentally simple code) or knows patterns (and overuses them). The expert writes intentionally simple code.

'More abstraction is better.'

Every abstraction has a cost: indirection, cognitive load, barrier to understanding. Abstractions are justified only when they reduce net complexity—when the problem they solve is larger than the complexity they introduce.

The Status Game

Let's be honest about an uncomfortable truth: pattern usage is a status marker. Using sophisticated patterns signals technical expertise. It marks you as someone who's 'read the books' and understands 'real' software engineering.

This creates perverse incentives:

• Code reviews reward pattern application ('Nice use of Strategy pattern!')
• Interviews reward pattern recognition and implementation
• Technical discussions favor pattern vocabulary
• 'Clean code' is implicitly equated with 'patterned code'

In this environment, simplicity is punished. Writing straightforward code looks less sophisticated than writing patterned code, even when straightforward code is better. Developers—being rational actors in this status game—reach for patterns to signal competence.

Recognizing this dynamic is the first step to resisting it. The goal is to optimize for project success, not for appearing sophisticated.

Pattern for pattern's sake manifests in various forms, each with distinct characteristics. Recognizing these patterns (of anti-patterns) helps identify the problem in your codebase or team.

Symptom 1: Premature Abstraction

The first implementation is already abstracted behind interfaces, factories, and strategies—before any actual variation exists or is needed.

What it looks like:

// We have one payment method. Just one. Credit cards.
// Yet we've built:
interface PaymentStrategy { ... }
class CreditCardPaymentStrategy implements PaymentStrategy { ... }
class PaymentStrategyFactory { ... }
class PaymentContext { ... }

// When we could have:
class PaymentService {
    async chargeCreditCard(card: CreditCard, amount: Money): Promise<Receipt> { ... }
}

The justification: 'We might add PayPal or Bitcoin later.'

The reality: When (if) those payment methods arrive, requirements will be clearer. The current abstraction, designed without knowledge of actual needs, may not fit. You'll refactor anyway—but with the burden of existing infrastructure.

The principle: Build concrete first, abstract when necessary.

Symptom 2: Speculative Generality

Code is written to handle cases that don't exist, won't exist, and may never exist—all in the name of 'flexibility.'

What it looks like:

// A configuration system that handles all of:
// - Multiple serialization formats
// - Distributed configuration sources
// - Hot reloading
// - Schema validation
// - Migration between versions

// Actual requirements:
// - Read config.json on startup

The justification: 'This is how enterprise configuration systems work.'

The reality: You're not building an enterprise. You're building your specific project with your specific needs. Every unused capability is maintenance burden.

The principle: Build for requirements you have, not requirements you imagine.

Symptom 3: Forced Pattern Fitting

The problem is reshaped to fit a pattern, rather than selecting a pattern (or no pattern) that fits the problem.

What it looks like:

Developer learns Observer pattern. Sees any communication between components. Forces it into Observer, even when direct method calls would be clearer. The notification system that notifies one thing. The event bus with one event type. The publisher with one subscriber.

The justification: 'This is the proper way to decouple.'

The reality: Decoupling has costs. Indirect communication is harder to trace, debug, and understand. Decoupling is justified when you need independent deployment, multiple subscribers, or genuine modularity. Decoupling for its own sake is indirection without benefit.

The principle: Let the problem shape the solution, not the pattern shape the problem.

Every pattern carries costs. The decision to use a pattern should explicitly acknowledge and weigh these costs against the benefits—yet pattern worshippers often treat patterns as free.

The Cost-Benefit Framework:

Before applying any pattern, explicitly calculate:

COSTS:

• Lines of code added
• New concepts introduced
• Testing overhead
• Onboarding time for new developers
• Maintenance burden over the project lifetime

BENEFITS:

• Specific problems solved
• Flexibility that will be used
• Clarity improvements (yes, patterns can improve clarity—when applied correctly)
• Testing improvements (some patterns significantly improve testability)
• Team alignment (shared vocabulary can help larger teams)

THE RULE: Benefits must exceed costs by a significant margin. If it's close, prefer simplicity. Patterns that barely pay for themselves aren't worth the risk of being wrong.

Having spent significant effort cautioning against pattern overuse, let's establish clear, rigorous criteria for when patterns are genuinely necessary. These aren't suggestions—they're requirements for pattern application.

Refusing patterns requires confidence—confidence that simplicity is a virtue, that expertise includes restraint, and that solving today's problems beats preparing for tomorrow's imaginations.

Developing Pattern Skepticism

Healthy pattern skepticism isn't anti-pattern dogma. It's a calibrated default toward simplicity that requires patterns to prove their worth.

The skeptic's questions:

1. 'What problem does this solve?'

   • If the answer is vague, the problem probably isn't real.
   • 'It adds structure' or 'It's more organized' aren't problems solved.

2. 'What's the simple alternative?'

   • Always sketch the simplest possible solution first.
   • If the simple solution is acceptable, stop there.

3. 'Who benefits from this pattern?'

   • If the answer is 'future developers' or 'extensibility,' be suspicious.
   • Real beneficiaries are usually identifiable: 'The team adding payment methods' or 'The testing suite.'

4. 'What's the cost of being wrong?'

   • If you add a pattern and it's unnecessary, you've added maintenance burden.
   • If you skip a pattern and it's needed, you can add it later.
   • Asymmetric costs favor simplicity.

Pushing Back in Code Reviews

Pattern pressure often comes in code reviews. Here's how to push back constructively:

Pattern advocate: 'This should use the Strategy pattern for the different validation types.'

Skeptic response: 'Currently we have two validation types that never change. Can you describe a scenario where we'd need to add or swap strategies at runtime? If not, the switch statement is clearer and we can refactor when the need arises.'

Pattern advocate: 'We should add an interface for this class so it can be mocked in tests.'

Skeptic response: 'Are we planning to write unit tests that mock this component? If we're doing integration or end-to-end tests, the interface adds no value. Let's add it when we need it.'

Pattern advocate: 'This should go through a Factory for consistent object creation.'

Skeptic response: 'What does the Factory provide that the constructor doesn't? If it's just calling new with the same parameters, it's an extra layer without benefit.'

Building Organizational Permission

In some organizations, simplicity needs cultural backing. Here's how to build it:

1. Establish 'Simple First' as a Principle

   • Add it to your team's engineering principles document.
   • 'We prefer the simplest solution that meets current requirements. Abstractions require justification.'

2. Celebrate Simplifications

   • When someone removes pattern complexity successfully, recognize it explicitly.
   • 'Great refactoring—the new version is 60% less code with the same functionality.'

3. Question Complexity in Architecture Reviews

   • Make 'What's the simpler alternative?' a standard question.
   • Require explicit cost-benefit analysis for significant patterns.

4. Measure What Matters

   • Time to understand a feature.
   • Time to onboard new developers.
   • Test complexity versus code covered.
   • These metrics expose the cost of over-patterning.

Let's examine several scenarios where pattern skepticism guides better design decisions.

Case Study 1: The Unnecessary Repository Layer

Situation: A team building a small internal tool adds a Repository layer over their database, with interfaces for each repository and multiple implementations.

Justification: 'This allows us to swap databases or use in-memory storage for tests.'

Reality check:

• The application has been on PostgreSQL for two years and will stay there.
• Tests use a real test database, not mocks.
• The 'flexibility' has never been used.

Skeptic's verdict: The Repository layer adds 15 classes with no practical benefit. Direct database access through a simple data access object would suffice. If database portability ever becomes a requirement, the abstraction can be added then—informed by actual requirements rather than speculation.

The simpler alternative:

// Instead of: IUserRepository, UserRepository, InMemoryUserRepository, etc.
// Just use:
class UserData {
    constructor(private db: Database) {}
    
    async findById(id: string): Promise<User | null> {
        return this.db.query('SELECT * FROM users WHERE id = $1', [id]);
    }
    // Direct, clear, testable with a real test database
}

Case Study 2: The Observer That Observes Nothing

Situation: A notification system uses an Observer pattern with Subject and Observer interfaces, concrete implementations, and a registration mechanism.

Justification: 'This decouples the notification sender from receivers.'

Reality check:

• There's one sender and one receiver.
• They're in the same codebase, same repository, deployed together.
• The 'decoupling' requires more code than direct coupling.

Skeptic's verdict: Direct method invocation is simpler and achieves the same result:

// Instead of:
class OrderSubject implements Subject {
    notify(event: OrderEvent) { this.observers.forEach(o => o.update(event)); }
}
class EmailObserver implements Observer {
    update(event: OrderEvent) { /* send email */ }
}

// Just use:
class OrderService {
    async createOrder(request: OrderRequest) {
        const order = await this.saveOrder(request);
        await this.emailService.sendOrderConfirmation(order);
    }
}

The direct call is more readable, easier to debug, and loses nothing because there's no polymorphism in the observers.

Case Study 3: The Factory With One Product

Situation: Object creation goes through a Factory class that constructs exactly one type of object.

Justification: 'This centralizes creation logic and allows us to change how objects are created.'

Reality check:

• The creation logic is a simple constructor call.
• If creation were complex, the complexity would live in the constructor anyway.
• No alternative creation paths exist or are planned.

Skeptic's verdict: A constructor is already a factory for its class. Adding another layer is pure ceremony:

// Instead of:
class UserFactory {
    create(name: string, email: string): User {
        return new User(name, email);
    }
}

// Just use:
const user = new User(name, email);

// When creation becomes complex:
class User {
    // Put the complexity where it belongs: in the class itself
    static createWithDefaults(name: string): User {
        return new User(name, `${name}@default.com`, DefaultRole, new Date());
    }
}

Factories are for when you don't know which class to instantiate, or when creation requires complex coordination of multiple objects. For straightforward construction, constructors exist for a reason.

Pattern wisdom—knowing when to use patterns and when to refrain—develops through experience, reflection, and deliberate practice. Here's how to cultivate it:

The journey of pattern maturity:

Stage 1: Pattern Ignorance

• You don't know patterns.
• You write simple code because you have no other option.
• Simple code isn't a choice; it's a limitation.

Stage 2: Pattern Discovery

• You learn patterns.
• Everything looks like a pattern opportunity.
• You over-apply, creating complexity.
• This is a necessary stage—you can't develop judgment without experience.

Stage 3: Pattern Disillusionment

• You experience the costs of over-patterning.
• You remove patterns you added.
• You start to question pattern recommendations.

Stage 4: Pattern Wisdom

• You know patterns deeply.
• You choose simplicity deliberately.
• Patterns are used rarely, precisely, with clear justification.
• Simple code is now an achievement, not a default.

Most developers who learn patterns go through Stages 1-3. The goal is to reach Stage 4—knowing when not to use the tools you've mastered.

We've explored the anti-pattern of 'pattern for pattern's sake' in depth. Let's consolidate the key insights:

What's next:

Having explored over-patterning and pattern worship, we'll conclude this module with the positive principle that should guide all design decisions: Keeping It Simple. We'll examine simplicity as a design virtue, how to achieve it while meeting real requirements, and how to balance simplicity with the genuine complexity that some problems require.