Anti-Patterns and Pattern Abuse

There's a famous quote, often attributed to various programming luminaries: 'Simple can be harder than complex. You have to work hard to get your thinking clean to make it simple.'

This captures a fundamental truth about software development: simplicity is not the absence of effort—it's the result of tremendous effort. Anyone can add complexity. Complexity is the default. Complexity is what happens when you're in a hurry, when requirements are unclear, when you're not sure what you're doing. Simplicity, by contrast, requires clarity of thought, discipline, and often the courage to discard work that didn't lead where you needed to go.

Simplicity isn't just aesthetically pleasing—it's a first-order engineering concern that directly impacts every aspect of software development and maintenance.

Why simplicity matters:

The compounding effect of simplicity:

Simplicity compounds over time. Simple systems stay simple because changes are isolated. Complex systems become more complex because each change must navigate existing complexity, often adding more.

Consider two codebases at Year 1:

Codebase A (Simple): 10,000 lines. New feature takes 1 week. Codebase B (Complex): 25,000 lines for the same functionality. New feature takes 3 weeks due to understanding overhead.

At Year 3:

Codebase A: 30,000 lines. New feature takes 1.5 weeks. Growth is linear. Codebase B: 100,000 lines. New feature takes 2 months. Each change adds complexity, and understanding overhead grows exponentially.

This isn't hypothetical—it's the observed pattern in real systems. Simplicity at the start creates simplicity at scale. Complexity at the start compounds into crisis.

Fred Brooks, in his famous essay 'No Silver Bullet,' distinguished between two types of complexity:

The builder's responsibility:

Our job as software engineers is to:

1. Honor essential complexity — Don't pretend the problem is simpler than it is. Hiding essential complexity creates systems that fail when reality intrudes.

2. Eliminate accidental complexity — Ruthlessly remove complexity we've introduced. Question every abstraction, every pattern, every layer.

3. Distinguish between them correctly — This is the hard part. What looks essential might be accidental; what seems accidental might be essential.

Common sources of accidental complexity:

• Overengineering — Building for imagined scale, flexibility, or features
• Pattern misuse — The subject of this entire module
• Framework overhead — Using heavy tools for light problems
• Copy-paste evolution — Duplicating code instead of abstracting appropriately
• Fear of refactoring — Working around problems instead of fixing them
• Unclear requirements — Building multiple solutions when requirements aren't understood

Each of these is addressable. Accidental complexity is chosen, even when the choice is unconscious. Choosing differently—choosing simplicity—is always possible.

Simplicity is aspirational without practical techniques. Here are concrete strategies that working engineers use to achieve and maintain simplicity:

Strategy 1: Start Concrete, Generalize Later

The natural instinct is to plan for flexibility upfront. Resist it.

The practice:

• Write the specific solution for your specific problem
• Watch for patterns to emerge from actual code, not anticipated needs
• Generalize only when you have three concrete cases

Why it works: Concrete code teaches you about the problem. Premature abstractions encode assumptions that may be wrong. By starting concrete, you learn what flexibility is actually needed—and can design appropriate abstractions with that knowledge.

// DON'T: Abstract immediately
interface NotificationChannel {
    send(user: User, message: string): Promise<void>;
}
class EmailChannel implements NotificationChannel { ... }
class SmsChannel implements NotificationChannel { ... }

// DO: Start concrete
class NotificationService {
    async notifyByEmail(user: User, message: string): Promise<void> {
        await this.emailClient.send(user.email, message);
    }
}

// When you add SMS for a second time:
class NotificationService {
    async notifyByEmail(user: User, message: string): Promise<void> { ... }
    async notifyBySms(user: User, message: string): Promise<void> { ... }
}

// When you add the third channel AND need dynamic dispatch:
// THEN create the abstraction, with knowledge of what it needs

Strategy 2: Inline Until It Hurts

Don't extract methods, classes, or modules until the duplication or complexity is causing problems.

The practice:

• Let code get 'messy' before extracting
• Feel the pain of duplication before abstracting it away
• Extract when three or more copies exist, or when a method exceeds ~30 lines of coherent logic

Why it works: Premature extraction often extracts the wrong thing. By waiting until the mess is real, you know exactly what needs extraction and how the abstraction should be shaped. The pain guides the design.

The threshold:

• 1-2 copies: Leave inline. Coincidental similarity isn't meaningful.
• 3+ copies: Extract. This is a pattern worth naming.
• 30+ lines in a method: Consider extraction for readability, not reuse.

Strategy 3: Delete More Than You Add

Healthy codebases shrink as often as they grow. If your codebase only grows, complexity is accumulating.

The practice:

• Before adding features, look for code that can be removed
• Regularly evaluate: 'Is this still needed?'
• Make deletion a first-class activity, not an afterthought

Why it works: Deletion directly reduces complexity. Every line deleted is a line that never needs to be read, understood, tested, or maintained. Dead code, unused features, and vestigial abstractions should be removed aggressively.

What to delete:

• Code for features that aren't used
• Abstractions with only one implementation
• 'Just in case' infrastructure that never got used
• Comments that restate the code
• Tests for deleted functionality

Strategy 4: Prefer Plain Code Over Clever Code

Clever code is fun to write and painful to maintain. Plain code is boring to write and a joy to maintain.

The practice:

• Use explicit control flow (if/else) over implicit (strategy patterns, polymorphic dispatch) when there are few cases
• Prefer simple data structures (arrays, maps) over elaborate class hierarchies
• Name things obviously, not cleverly

Why it works: Plain code can be understood by reading it. Clever code requires understanding the system's design. Plain code works for new team members from day one. Clever code requires initiation.

// CLEVER: Elegant but requires understanding the visitor pattern
function processNode(node: ASTNode): Result {
    return node.accept(new ProcessingVisitor());
}

// PLAIN: Boring but immediately understandable
function processNode(node: ASTNode): Result {
    switch (node.type) {
        case 'literal': return processLiteral(node);
        case 'binary': return processBinary(node);
        case 'call': return processCall(node);
        default: throw new Error(`Unknown node: ${node.type}`);
    }
}
// The plain version is longer but infinitely more debuggable

Simplicity manifests differently at different architectural levels. Let's examine what simplicity looks like from functions to systems:

Function-Level Simplicity

A simple function:

• Does one thing and does it completely
• Has a descriptive name that matches its behavior
• Takes minimal parameters (0-3 typically)
• Has no hidden dependencies or side effects
• Can be understood without reading its callers or callees

// SIMPLE: Clear purpose, obvious inputs/outputs
function calculateTax(subtotal: Money, taxRate: Percentage): Money {
    return subtotal.multiply(taxRate);
}

// COMPLEX: Multiple responsibilities, hidden dependencies
function processPayment(order: Order): Result {
    const tax = taxService.getTaxRate(order.shipping.address, globalConfig.taxRules);
    order.total = order.subtotal * (1 + tax);
    const result = paymentGateway.charge(order.customer.card, order.total);
    if (result.success) {
        emailService.sendReceipt(order);
        analyticsService.track('payment', order);
        inventoryService.reserve(order.items);
    }
    return result;
}

The second function does too much. It calculates tax, processes payment, sends emails, tracks analytics, and manages inventory. Each of these should be separate, and the orchestration should be explicit.

Service-Level Simplicity

Simplicity scales up. A simple service:

• Has one clear purpose — 'Manages user authentication' or 'Processes payments.' Not 'Handles user stuff.'

• Owns its data — No shared databases. Services communicate through APIs, not shared state.

• Can be deployed independently — Changes to this service don't require coordinating with others.

• Has a minimal API surface — Exposes what's needed, hides everything else.

• Fails gracefully — Handles its dependencies being unavailable.

The distributed monolith—the opposite of simplicity:

When services share databases, require coordinated deployment, or have circular dependencies, you've recreated a monolith with network latency added. This is worse than either a simple monolith or properly independent services.

A common objection to simplicity: 'We need the complexity for features X, Y, and Z.' This conflates essential complexity (needed for features) with accidental complexity (introduced by poor design). Let's distinguish them:

Real-World Example: Payment Processing

The requirements:

• Accept credit cards and PayPal
• Handle multiple currencies
• Apply promotional discounts
• Manage subscriptions
• Handle refunds

This is genuinely complex. There's no simple solution that meets all requirements. But there are simpler and more complex implementations.

The complex approach:

• Abstract payment methods behind Strategy pattern (reasonable)
• Abstract currency conversion behind another Strategy (reasonable)
• Add Decorator for discounts on top of payment strategies (getting complex)
• Add Observer for subscription events (adding indirection)
• Add Command pattern for refundable operations (more abstraction)
• Add Abstract Factory for creating the right combination of strategies (now it's a maze)

The simpler approach:

• One PaymentService class with methods for each payment type
• Currency conversion as a utility function called where needed
• Discounts calculated before payment, not layered on top
• Subscriptions as a separate module with its own logic
• Refunds as explicit operations, not abstract commands

The simpler approach:

• Has more explicit code (more lines for payment methods)
• Has less abstraction (no Strategy, Decorator, etc.)
• Is much easier to understand and debug
• Meets exactly the same requirements

Simplicity is the default, but not the absolute. Some situations genuinely require complexity. Recognizing these situations prevents naive over-simplification:

The complexity checklist:

Before accepting complexity, verify:

1. Is the trigger real, current, and measurable?

   • Not 'we might need' but 'we need, and here's why.'

2. Is the complexity localized?

   • Complexity in one bounded context is acceptable.
   • Complexity that spreads is dangerous.

3. Is the complexity the minimum required?

   • Often there's a simpler way to achieve the same goal.
   • Have you explored alternatives?

4. Is the complexity documented?

   • Future developers will ask 'Why is this complex?'
   • The answer should be recorded near the code.

5. Is there a sunset condition?

   • If the trigger goes away, will the complexity be removed?
   • Or will it linger forever?

Example: Justified Complexity

Scenario: A notification system that sends to email, SMS, push notifications, and Slack, with per-user channel preferences and fallback logic.

Why complexity is justified:

• Four channels exist now (not speculatively)
• User choice requires runtime dispatch
• Fallback logic creates combinatorial behavior

The complexity:

interface NotificationChannel {
    supports(user: User): boolean;
    send(user: User, message: Message): Promise<NotificationResult>;
}

class NotificationService {
    constructor(private channels: NotificationChannel[]) {}
    
    async notify(user: User, message: Message): Promise<void> {
        const preferred = this.channels.filter(c => 
            user.preferences.enabled(c.name) && c.supports(user)
        );
        
        for (const channel of preferred) {
            const result = await channel.send(user, message);
            if (result.delivered) return;
            // Try next channel as fallback
        }
        
        throw new NotificationFailure('All channels failed');
    }
}

This is more complex than a single email sender. But the complexity is justified by actual requirements and localized to the notification module.

Starting simple is necessary but not sufficient. Systems tend toward complexity over time—entropy in action. Maintaining simplicity requires ongoing discipline:

The Simplification Reflex

Develop a reflex: whenever you touch code, leave it simpler than you found it. This doesn't mean rewriting everything—but if you see an unnecessary abstraction, remove it. If you see dead code, delete it. If you see a confusing function, clarify it.

The Boy Scout Rule for simplicity: 'Leave the codebase simpler than you found it.'

This small, consistent effort prevents complexity from accumulating. Each developer, making small improvements, creates a force against entropy.

Warning signs that simplicity is slipping:

• Time to implement 'simple' features is growing
• New developers take longer to become productive
• The same areas of code keep causing problems
• Developers are afraid to modify certain areas
• Testing requires more and more mock setup
• Documentation can't keep up with the system

We've explored simplicity as the counterbalance to pattern complexity. Let's consolidate the key insights from this page and the entire module:

Module Conclusion: Anti-Patterns and Pattern Abuse

Through this module, we've explored the shadow side of design patterns:

• Anti-patterns — Recurring solutions that cause more harm than good
• Over-patterning — Applying more patterns than the problem requires
• Pattern for pattern's sake — Using patterns as ends rather than means
• Keeping it simple — The discipline that keeps patterns in check

The goal isn't to avoid patterns—it's to use them with wisdom. Patterns are tools, and tools have appropriate uses. The master craftsperson knows not only how to use their tools but when to leave them in the box.

Your next challenge:

Review a codebase you work on. Identify one abstraction that might be unnecessary. Consider what the code would look like without it. If it would be simpler and still meet requirements, propose removing it.

This is the practice of pattern wisdom: not just adding good things, but having the courage to remove things that aren't earning their place.