Design is Iterative - Iterating and Refining Designs | OneNoughtOne

0/290

System Design (LLD)Iterating and Refining

Iterating and Refining Designs

LevelAdvanced

Duration60 mins

TopicIterating and Refining

1 / 4

Design is Iterative

The Myth of the Perfect First Draft

There's a pervasive myth in software engineering: the idea that experienced designers sit down, think deeply for a moment, and then produce a near-perfect design in a single pass. This myth is not just misleading—it's actively harmful to developing genuine design skill.

The reality is radically different. Every elegant, well-structured system you've ever admired went through dozens, sometimes hundreds, of iterations before reaching its final form. The clean architecture of a booking system, the intuitive API of a payment gateway, the extensible design of a rules engine—all of these emerged through a process of progressive refinement, not divine inspiration.

This page establishes a fundamental truth that will transform how you approach Low-Level Design: design is inherently iterative, and mastering the iteration process is as important as mastering design patterns or SOLID principles.

What You Will Learn

By the end of this page, you will understand why iteration is not a sign of weakness but a source of strength in design. You'll learn the psychology behind effective iteration, practical techniques for evolving designs, and how to structure your iteration process to maximize both learning and design quality.

The Psychology of Iterative Design

Before we discuss techniques, we need to address the psychology that makes iteration difficult for many engineers. Understanding these mental barriers is the first step to overcoming them.

Why we resist iteration:

Many developers feel that needing to iterate indicates failure or inadequacy. We've been trained to value getting things right the first time, and iteration can feel like admitting we got it wrong. This mindset is not just incorrect—it's the primary obstacle to becoming a better designer.

Consider what actually happens during design:

The Cognitive Reality of Design

•Incomplete Information — At the start of design, you never have all the information. Requirements are partially understood, edge cases are unknown, and the interaction between components isn't clear until you model it.
•Emergent Complexity — Decisions made early interact with decisions made later in ways that are impossible to predict. A class hierarchy that seemed perfect becomes awkward when the sixth use case appears.
•Growing Understanding — The very act of designing teaches you about the problem space. Your understanding at minute 60 is fundamentally deeper than your understanding at minute 1.
•Context Dependency — What works in one context may not work in another. A pattern that's perfect for a financial system might be overkill for a simple utility.
•Changing Requirements — Even if your initial understanding was perfect, requirements evolve. The business pivots, users reveal unexpected needs, and technical constraints shift.

Reframe Iteration as Strength

The best designers iterate more, not less. Their willingness to revisit and refine is what produces elegant results. Each iteration represents learning applied. An engineer who iterates three times and produces an excellent design has demonstrated more skill than one who stops at their first attempt because they're afraid to admit it could be better.

The growth mindset in design:

Psychologist Carol Dweck's research on growth mindset applies directly to design work. Engineers with a growth mindset view design challenges as opportunities to learn, while those with a fixed mindset see them as tests of their innate ability. This distinction has profound implications:

Fixed mindset: "If I have to change my design, I must not be a good designer."
Growth mindset: "Each revision teaches me something new about the problem."

The growth mindset isn't just more pleasant—it's more accurate. Design is a skill that develops through practice and feedback, not an innate talent you either have or don't.

The Anatomy of a Design Iteration

Not all iterations are created equal. A productive iteration follows a structured pattern that maximizes learning and minimizes wasted effort. Understanding this anatomy helps you iterate more effectively.

The Four Phases of Effective Iteration:

Every productive design iteration moves through four distinct phases. Skipping phases leads to shallow iterations that don't actually improve the design.

The Iteration Cycle
Phase	Activities	Key Questions	Output
Evaluate	Analyze current design against requirements and principles	Does this design meet functional requirements? Are SOLID principles violated? What are the pain points?	List of specific issues and concerns
Hypothesize	Generate potential improvements	What patterns might address this issue? Are there alternatives? What are the trade-offs?	Set of proposed changes with rationale
Apply	Implement the most promising change	How does this change affect other components? Does it introduce new issues?	Updated design artifacts
Reflect	Assess the impact of the change	Is the design better? Did we introduce new problems? What did we learn?	Lessons learned, next iteration decision

Example: Iterating on a Notification System Design

Let's walk through a concrete example to see these phases in action.

Initial Design (Iteration 0):

You're designing a notification system for an e-commerce platform. Your first design has a single NotificationService class that handles email, SMS, and push notifications directly.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
// Initial design: Single class handling all notification types
class NotificationService {
    private emailClient: EmailClient;
    private smsClient: SMSClient;
    private pushClient: PushNotificationClient;
    
    constructor(
        emailClient: EmailClient,
        smsClient: SMSClient,
        pushClient: PushNotificationClient
    ) {
        this.emailClient = emailClient;
        this.smsClient = smsClient;
        this.pushClient = pushClient;
    }
    
    sendNotification(
        userId: string,
        type: 'email' | 'sms' | 'push',
        message: string
    ): void {
        const user = this.getUser(userId);
        
        switch (type) {
            case 'email':
                this.emailClient.send(user.email, message);
                break;
            case 'sms':
                this.smsClient.send(user.phone, message);
                break;
            case 'push':
                this.pushClient.send(user.deviceToken, message);
                break;
        }
    }
    
    private getUser(userId: string): User { /* ... */ }
}

Iteration 1: Applying Evaluate-Hypothesize-Apply-Reflect

Evaluate Phase: Looking at this design, several issues emerge:

The switch statement violates the Open/Closed Principle—adding WhatsApp notifications requires modifying NotificationService
The class has too many responsibilities—it knows about all notification channels
Testing requires mocking all three clients even when testing just one channel
No clear abstraction for "notification channel"

Hypothesize Phase: Potential improvements:

Strategy Pattern: Define a NotificationChannel interface with implementations per channel
Factory Pattern: Create channels through a factory based on user preferences
Each channel handles its own delivery logic

Apply Phase: Let's refactor using the Strategy Pattern:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
// Iteration 1: Strategy Pattern for notification channels
 
interface NotificationChannel {
    send(user: User, message: string): void;
    supports(user: User): boolean;
}
 
class EmailChannel implements NotificationChannel {
    constructor(private emailClient: EmailClient) {}
    
    send(user: User, message: string): void {
        this.emailClient.send(user.email, message);
    }
    
    supports(user: User): boolean {
        return user.email !== null;
    }
}
 
class SMSChannel implements NotificationChannel {
    constructor(private smsClient: SMSClient) {}
    
    send(user: User, message: string): void {
        this.smsClient.send(user.phone, message);
    }
    
    supports(user: User): boolean {
        return user.phone !== null;
    }
}
 
class PushChannel implements NotificationChannel {
    constructor(private pushClient: PushNotificationClient) {}
    
    send(user: User, message: string): void {
        this.pushClient.send(user.deviceToken, message);
    }
    
    supports(user: User): boolean {
        return user.deviceToken !== null;
    }
}
 
// NotificationService now uses channels through abstraction
class NotificationService {
    constructor(private channels: NotificationChannel[]) {}
    
    sendNotification(user: User, message: string): void {
        for (const channel of this.channels) {
            if (channel.supports(user)) {
                channel.send(user, message);
            }
        }
    }
}

Reflect Phase:

What improved:

Adding new channels no longer requires modifying NotificationService (OCP satisfied)
Each channel can be tested in isolation
Clear abstraction makes the design easier to understand

What new questions arose:

Should we send to all supported channels, or let users choose preferences?
How do we handle delivery failures gracefully?
What about notification templates and formatting per channel?

These questions seed the next iteration. Notice that the act of improving the design revealed new considerations that weren't visible before.

Iteration Reveals Hidden Requirements

A key insight is that iteration doesn't just improve your design—it improves your understanding of the problem. The questions that arise during reflection often reveal requirements or edge cases that no one explicitly stated but that will definitely matter in production.

When to Iterate and When to Stop

Iteration is valuable, but it's not infinite. One of the skills that separates experienced designers from novices is knowing when to continue iterating and when to declare the design "good enough."

Signals that indicate you should continue iterating:

Keep Iterating When

•SOLID violations remain — If your design clearly violates one or more SOLID principles and there's a reasonable way to fix it, you should iterate.
•Core requirements aren't met — If the design doesn't fulfill functional requirements, iteration is mandatory, not optional.
•Significant coupling exists — If changing one component requires changes to many others, the design needs refinement.
•You're embarrassed to explain it — This gut check is surprisingly reliable. If you'd be uncomfortable presenting this design to a senior colleague, it probably needs work.
•Testing would be difficult — If you can already tell the design would be hard to unit test, that's a design smell worth addressing.
•Recent changes are getting harder — If each iteration is increasing complexity rather than reducing it, you may need a fundamentally different approach rather than incremental fixes.

Signals that indicate you can stop iterating:

Stop Iterating When

•Requirements are satisfied — All functional and identified non-functional requirements are addressed.
•SOLID principles are reasonably satisfied — No glaring violations remain (though perfection isn't the goal).
•Changes are cosmetic — Recent iterations are producing diminishing returns—moving method calls around rather than improving structure.
•You can explain it clearly — You can walk through the design and articulate why each decision was made.
•The design handles known edge cases — The design doesn't fall apart when you mentally simulate edge cases.
•Extension points are identified — You've identified where the design might need to change and ensured those points are flexible.

Beware of Analysis Paralysis

Perfectionism disguised as thoroughness can trap you in endless iteration. Remember: the goal is a design that's good enough to implement, not one that's theoretically perfect. Real-world feedback from implementation will inform further refinement. A shipped design that works is infinitely more valuable than a perfect design that's never built.

The 80/20 Rule in Design Iteration:

Typically, the first few iterations produce the most dramatic improvements. The first iteration might triple the design quality. The second iteration might improve it by 50%. By the fifth iteration, you're often making 5% improvements at best.

Recognizing this diminishing returns curve helps you allocate effort appropriately. For a critical core component, those small improvements might be worth pursuing. For a peripheral utility, stopping earlier is often wiser.

Iteration Investment by Component Criticality
Component Type	Suggested Iteration Depth	Rationale
Core domain entities	High (5+ iterations)	Central to the system; mistakes are costly; frequently touched code
Primary business logic	High (4-5 iterations)	Directly impacts user value; needs to be correct and maintainable
Infrastructure adapters	Medium (2-3 iterations)	Important but often replaceable; follow established patterns
Utility classes	Low (1-2 iterations)	Peripheral to core concerns; over-engineering is common trap
Prototypes/experiments	Minimal (1 iteration)	Meant to be thrown away; quick feedback is the goal

Techniques for Effective Iteration

Having established the philosophy and timing of iteration, let's explore practical techniques that make iteration more effective.

Technique 1: The Refactoring Mindset

Approach design iteration the same way you approach code refactoring: small, safe steps that preserve behavior while improving structure. This mindset prevents the common failure mode of "let me just start over," which often loses valuable learning embedded in the current design.

The Refactoring Approach to Design

•Identify one specific issue — Don't try to fix everything at once. Pick the most pressing problem.
•Propose the minimal change — What's the smallest modification that addresses this issue?
•Verify other aspects remain intact — Make sure you haven't broken something that was working.
•Document the change and rationale — This creates a trail that helps you and others understand the design's evolution.
•Move to the next issue — Repeat the process for the next most pressing problem.

Technique 2: Design Spikes

Sometimes you're uncertain which of several approaches would work best. Rather than picking one and hoping, consider running a design spike: a quick, time-boxed exploration of multiple alternatives.

Set a time limit (e.g., 30 minutes per approach)
Sketch each alternative enough to understand its implications
Compare the alternatives against your quality criteria
Select the winner and continue from there

This technique prevents the sunk cost fallacy—the tendency to stick with an approach because you've already invested time in it, even when an alternative would be better.

Sketch, Don't Polish

During design spikes, resist the urge to fully detail each alternative. You're exploring, not committing. A rough sketch that captures the key abstraction and a few class names is enough to evaluate an approach. Save the detail work for after you've chosen your direction.

Technique 3: Role-Playing the Design

One powerful iteration technique is to mentally "execute" your design by walking through scenarios as if you were the code. For each scenario:

Identify the entry point (which class/method receives the initial request)
Trace the flow through your classes and methods
Note where you feel friction—places where the flow is awkward, confusing, or requires excessive jumping between classes
Mark these friction points for potential iteration

This technique is especially valuable for catching:

Hidden coupling: When tracing a flow requires extensive knowledge of other classes
Missing abstractions: When a concept keeps appearing but has no explicit representation
Responsibility misplacement: When logic ends up in an unexpected class

Technique 4: The "Explain to a Colleague" Test

Imagine explaining your design to a colleague who's smart but unfamiliar with the specifics. As you mentally walk through the explanation:

Where do you feel the need to apologize or add caveats? ("This is a bit hacky, but...")
Where do you struggle to articulate the rationale? ("It's just how we've always done it.")
Where do you expect questions or pushback?

These points often indicate areas that need iteration. If you can't explain why a decision was made, it may not have been a good decision.

Technique 5: Future Extension Simulation

Identify three likely future requirements (based on product roadmap, industry patterns, or reasonable speculation). Mentally trace how your design would accommodate each:

Adding a new notification channel
Supporting bulk operations
Adding an audit trail

If accommodating these extensions would require major surgery, consider whether the current design adequately separates concerns and provides appropriate extension points.

Balance Present and Future

Don't over-engineer for unlikely futures, but do ensure your design doesn't paint you into a corner for likely ones. The goal isn't to anticipate every possible change but to ensure that common evolution patterns can be accommodated without rewriting the core design.

Common Iteration Anti-Patterns

Just as there are productive iteration patterns, there are anti-patterns that waste time and often make designs worse. Recognizing these helps you avoid falling into them.

Iteration Anti-Patterns to Avoid

•The Oscillation — Going back and forth between two approaches without making progress. If you find yourself reverting changes you made two iterations ago, step back and analyze why neither approach is satisfying.
•The Gold-Plating — Adding sophistication that isn't needed. Each iteration should address a real problem, not add features 'just in case.' If you can't articulate what problem an iteration solves, it's probably gold-plating.
•The Kitchen Sink — Trying to address too many issues in a single iteration. This makes it hard to evaluate the impact of changes and increases the risk of introducing new problems.
•The Wheel Reinvention — Ignoring established patterns in favor of custom solutions. If a well-known pattern addresses your problem, use it. Iteration doesn't mean inventing everything from scratch.
•The Premature Abstraction — Creating abstractions before you understand what needs to vary. Abstractions have costs; create them when concrete need emerges, not speculatively.
•The Sunk Cost Trap — Continuing to iterate on a fundamentally flawed approach because you've invested time in it. Sometimes the right iteration is to start fresh from a different conceptual foundation.

Healthy vs. Unhealthy Iteration Signs
Healthy Sign	Unhealthy Sign
Each iteration reduces complexity or increases clarity	Iterations add more classes without clear benefit
You can articulate what each iteration accomplished	You can't explain why you made recent changes
Changes are getting smaller as design stabilizes	Changes are getting larger, indicating fundamental issues
You're addressing issues from evaluation criteria	You're making changes based on vague feelings
The design is easier to test after each iteration	Testing considerations aren't improving
You feel more confident explaining the design	You feel increasingly uncertain about justify decisions

When to Reset

If you notice multiple unhealthy signs, it may be time to step back rather than continue iterating. Question your fundamental assumptions: Are the entities correct? Is the core abstraction sound? Sometimes the bravest iteration is acknowledging that the foundation needs rethinking.

Iteration in Interview Context

LLD interviews, despite their time constraints, expect and reward iterative thinking. Interviewers are evaluating not just your final design but your ability to evolve it based on feedback and changing requirements.

How interviews simulate iteration:

Typical interview dynamics that test your iteration skills:

Interview Iteration Scenarios

•"What if we need to add X?" — The interviewer is testing whether your design accommodates extensions. A good response shows how your abstraction handles the new requirement with minimal changes.
•"Have you considered Y?" — This might be a probe to see if you're aware of an issue in your design. Acknowledge it gracefully and explain how you'd refine the design.
•"How would this scale?" — Often reveals that your initial design has bottlenecks. Being willing to iterate on the scale concern demonstrates maturity.
•"What trade-offs are you making?" — The interviewer wants to see that you recognize alternatives and have reasons for your choices.

Demonstrating iterative thinking in interviews:

Start simple, then elaborate: Begin with a straightforward design and explicitly state that you'll refine it. This sets the expectation that iteration is coming.
Verbalize your evaluation: As you review your design, say things like "Looking at this, I notice that adding a new notification type would require modifying this class, which violates Open/Closed. Let me refine this..."
Propose before implementing: Before making a change, briefly explain what you're about to do and why. "I'm going to extract an interface here so that we can swap implementations for testing."
Embrace interviewer feedback: When an interviewer suggests a change or asks about an extension, treat it as valuable input for iteration, not criticism.
Time-box your iterations: In a 45-minute interview, you might go through 2-3 major design iterations. Don't spend 40 minutes on the first version—leave time to show you can refine.

Interviewers Look for Growth

A candidate who starts with a basic design and thoughtfully iterates to a solid solution often scores higher than one who presents a complex design immediately. The iteration demonstrates problem-solving process, which is what interviewers are really evaluating.

Summary: Embracing Iterative Design

We've covered significant ground on why and how to iterate effectively. Let's consolidate the key takeaways:

Key Takeaways

•Design is inherently iterative — Great designs emerge through refinement, not through perfect first drafts. This is a feature, not a bug.
•Iteration requires the right mindset — A growth mindset that views each iteration as learning, rather than failure, is essential for effective design.
•Follow the Evaluate-Hypothesize-Apply-Reflect cycle — Structured iteration outperforms random changes. Each phase has a purpose.
•Know when to stop — Iteration has diminishing returns. Learn to recognize when a design is 'good enough' and when further iteration would be gold-plating.
•Use concrete techniques — Design spikes, role-playing scenarios, and the 'explain to a colleague' test are practical tools for productive iteration.
•Avoid iteration anti-patterns — Oscillation, gold-plating, and sunk cost thinking waste time and often degrade designs.
•Iteration is valued in interviews — Demonstrating iterative thinking shows process maturity that interviewers actively look for.

What's Next:

Now that we understand that design is iterative, the next page focuses on a critical input to iteration: feedback. We'll explore how to gather, evaluate, and incorporate feedback from various sources—whether from colleagues, stakeholders, or the requirements themselves—to drive productive iterations.

Page Complete

You now understand that iterative design is not a sign of weakness but the hallmark of professional engineering practice. In the next page, we'll examine how to systematically incorporate feedback into your design iterations to accelerate learning and improve quality.