From Design to Code - Learning Module

Loading content...

0/246

Incremental Implementation

Building Software Like Building a House

No one builds a house by completing one room entirely—walls, electrical, plumbing, paint, furniture—before starting the next. That approach would be inefficient, inflexible, and would hide problems until too late.

Instead, builders work in layers: foundation for the entire house, then framing for all rooms, then electrical throughout, then plumbing, then drywall, then finishes. Each layer is complete and inspected before the next begins.

Incremental implementation applies this same wisdom to software. Rather than completing one class before starting the next, you build the system in functional layers—each one working, tested, and validated before adding the next.

This approach is essential for:

Catching errors early — Problems surface before they're buried under more code
Maintaining morale — Working software at every step provides psychological momentum
Enabling pivots — Stakeholder feedback can be incorporated before you're too deep
Interview success — Demonstrating a working system, even partial, is far better than incomplete everything

What You Will Learn

By the end of this page, you will understand the incremental implementation philosophy, techniques for identifying implementation layers, strategies for maintaining a working system at each step, how to prioritize which functionality to implement first, and how to apply incremental implementation under interview time pressure.

The Philosophy of Incremental Development

Incremental development isn't about writing less code—it's about writing code in an order that maximizes value and minimizes risk at every step.

The Core Insight:

At any point during development, you should have a working system that does something useful. This "something" might be limited, but it's functional and correct. Each increment extends what the system can do.

Contrast with Big-Bang Development:

Aspect	Big-Bang Approach	Incremental Approach
First working system	After all code is written	After first increment
Error discovery	At the end (expensive to fix)	Immediately (cheap to fix)
Stakeholder feedback	After completion	After each increment
Risk exposure	High throughout, drops suddenly at end	Continuously decreasing
Team morale	Low until completion	Steady progress visible
Flexibility	Committed to original plan	Can pivot based on learning

Big-Bang Anti-Patterns

•Writing all classes before testing any
•Implementing every feature before deploying
•Building the entire UI before backend works
•Coding for days without running the program
•Completing all error handling before happy path

Incremental Patterns

•Test each class as it's completed
•Deploy with minimal features, add more over time
•Build one user flow end-to-end first
•Run and validate code every 15-30 minutes
•Get happy path working, then add error handling

The Interview Advantage

In interviews, incrementalism is essential. A candidate who shows a working parking lot system that handles cars (but not trucks or motorcycles) will score higher than one who has half-implemented code for all vehicle types. Working code demonstrates competence; incomplete code raises questions.

Vertical Slices vs. Horizontal Layers

There are two primary strategies for incremental implementation:

Horizontal Layers: Build entire infrastructure layers before functionality

First: All models
Then: All repositories
Then: All services
Then: All controllers

Vertical Slices: Build complete user flows, one at a time

First: Login flow (model + repo + service + controller)
Then: Create post flow (model + repo + service + controller)
Then: View feed flow (model + repo + service + controller)

The Modern Preference: Vertical Slices

Vertical slices are generally preferred because they produce working functionality faster. After the first slice, you have a usable system. With horizontal layers, you have usable code only after all layers are complete.

Vertical vs Horizontal Implementation
TypeScript
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
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
// ================================================
// Scenario: Building a Library Management System
// Features: Browse books, Checkout book, Return book, Manage members
// ================================================
 
// ================================================
// HORIZONTAL APPROACH (Not Recommended)
// ================================================
 
// Week 1: All models
class Book { /* ... */ }
class Member { /* ... */ }
class Loan { /* ... */ }
class Librarian { /* ... */ }
class Fine { /* ... */ }
class Reservation { /* ... */ }
 
// Week 2: All repositories
class BookRepository { /* ... */ }
class MemberRepository { /* ... */ }
class LoanRepository { /* ... */ }
// ... etc
 
// Week 3: All services
class BookService { /* ... */ }
class MemberService { /* ... */ }
class LoanService { /* ... */ }
// ... etc
 
// Week 4: Finally, a working feature!
// Problem: No working system until Week 4
// Problem: Errors in Week 1 models discovered in Week 4
 
// ================================================
// VERTICAL SLICE APPROACH (Recommended)
// ================================================
 
// --- SLICE 1: Browse Books (simplest feature) ---
 
// Just enough model
class Book {
    constructor(
        private readonly isbn: string,
        private title: string,
        private author: string
    ) {}
    
    getIsbn(): string { return this.isbn; }
    getTitle(): string { return this.title; }
    getAuthor(): string { return this.author; }
}
 
// Just enough repository
interface BookRepository {
    findAll(): Promise<Book[]>;
    findByIsbn(isbn: string): Promise<Book | null>;
    searchByTitle(query: string): Promise<Book[]>;
}
 
class InMemoryBookRepository implements BookRepository {
    private books: Book[] = [];
    
    async findAll(): Promise<Book[]> {
        return [...this.books];
    }
    
    async findByIsbn(isbn: string): Promise<Book | null> {
        return this.books.find(b => b.getIsbn() === isbn) || null;
    }
    
    async searchByTitle(query: string): Promise<Book[]> {
        const lowerQuery = query.toLowerCase();
        return this.books.filter(b => 
            b.getTitle().toLowerCase().includes(lowerQuery)
        );
    }
    
    // For seeding test data
    addBook(book: Book): void {
        this.books.push(book);
    }
}
 
// Just enough service
class BookBrowsingService {
    constructor(private bookRepo: BookRepository) {}
    
    async getAllBooks(): Promise<Book[]> {
        return this.bookRepo.findAll();
    }
    
    async searchBooks(query: string): Promise<Book[]> {
        return this.bookRepo.searchByTitle(query);
    }
}
 
// ✅ CHECKPOINT: "Browse Books" feature is COMPLETE and WORKING
// Can demo, can test, can get feedback
// Total time: ~30 minutes
 
// --- SLICE 2: Checkout Book ---
 
// Extend Book model
class BookV2 {
    private available: boolean = true;
    
    constructor(
        private readonly isbn: string,
        private title: string,
        private author: string
    ) {}
    
    isAvailable(): boolean { return this.available; }
    checkout(): void { this.available = false; }
    returnBook(): void { this.available = true; }
    // ... previous methods
}
 
// Add Member model
class Member {
    constructor(
        private readonly id: string,
        private name: string,
        private email: string
    ) {}
    
    getId(): string { return this.id; }
    getName(): string { return this.name; }
}
 
// Add Loan model
class Loan {
    constructor(
        private readonly id: string,
        private book: BookV2,
        private member: Member,
        private dueDate: Date,
        private checkoutDate: Date = new Date()
    ) {}
    
    getId(): string { return this.id; }
    getBook(): BookV2 { return this.book; }
    getMember(): Member { return this.member; }
    getDueDate(): Date { return this.dueDate; }
}
 
// Add repositories
interface MemberRepository {
    findById(id: string): Promise<Member | null>;
}
 
interface LoanRepository {
    save(loan: Loan): Promise<void>;
    findActiveByMember(memberId: string): Promise<Loan[]>;
}
 
// Add checkout service
class CheckoutService {
    constructor(
        private bookRepo: BookRepository,
        private memberRepo: MemberRepository,
        private loanRepo: LoanRepository
    ) {}
    
    async checkoutBook(isbn: string, memberId: string): Promise<Loan> {
        const book = await this.bookRepo.findByIsbn(isbn);
        if (!book) throw new Error("Book not found");
        if (!book.isAvailable()) throw new Error("Book not available");
        
        const member = await this.memberRepo.findById(memberId);
        if (!member) throw new Error("Member not found");
        
        const dueDate = new Date();
        dueDate.setDate(dueDate.getDate() + 14); // 2 weeks
        
        const loan = new Loan(
            `loan_${Date.now()}`,
            book,
            member,
            dueDate
        );
        
        book.checkout();
        await this.loanRepo.save(loan);
        
        return loan;
    }
}
 
// ✅ CHECKPOINT: "Checkout Book" feature is COMPLETE and WORKING
// Browse + Checkout both work
// Total time: ~1 hour
 
// --- SLICE 3: Return Book ---
// Extends Loan, adds return logic, adds fine calculation
// Total time: ~30 minutes more
 
// --- SLICE 4: Manage Members ---
// CRUD for members
// Total time: ~30 minutes more
 
// ================================================
// COMPARISON
// ================================================
 
// Horizontal: 4 weeks until any feature works
// Vertical: Working feature every 30-60 minutes
// 
// With vertical slices:
// - After 30 min: Can demo book browsing
// - After 1 hour: Can demo checkout
// - Errors in Book model found in Slice 1, not Slice 4
// - Stakeholder can use partial system and give feedback

When Horizontal Makes Sense

Horizontal layering is appropriate when infrastructure must be in place before any feature works (e.g., authentication, database setup), or when multiple features share common infrastructure that's expensive to retrofit. Even then, implement the minimal horizontal layer needed for the first vertical slice.

Prioritizing What to Implement First

Not all increments are equal. Some provide more value, reduce more risk, or enable more subsequent work. Prioritization determines which increments to tackle first.

The Prioritization Framework:

Consider four factors:

Value — How much user/business value does this provide?
Risk — How much uncertainty does this eliminate?
Dependency — How many other things depend on this?
Effort — How much work is required?

Priority Matrix:

Increment Prioritization
Priority	Characteristics	Action	Examples
1 - Critical	High value, many dependents, high risk	Do first	Core entities, primary user flow, main abstraction
2 - Important	High value or many dependents	Do second	Secondary flows, key edge cases, integration points
3 - Nice to Have	Moderate value, few dependents	Do if time permits	Additional features, UI polish, optimizations
4 - Defer	Low value, high effort	Skip or stub	Rare edge cases, admin features, analytics

The "Walking Skeleton" Approach:

A walking skeleton is the minimal end-to-end flow that exercises all layers of the system. It's the first increment in many projects:

Web app: User clicks button → Server receives request → Database queried → Response returned → Page updated
Parking lot: Vehicle arrives → Ticket issued → Spot assigned
Payment system: Card submitted → Charge processed → Receipt generated

The walking skeleton proves the architecture works. Everything else is incremental enhancement.

Increment Prioritization Example
TypeScript
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
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
// ================================================
// Scenario: Elevator System
// ================================================
 
// Identify all potential increments:
const allIncrements = [
    // Core functionality
    { name: "Single elevator moves up/down", priority: 1 },
    { name: "Elevator responds to floor button", priority: 1 },
    { name: "Elevator doors open/close", priority: 1 },
    
    // Secondary functionality
    { name: "Multiple elevators coordinated", priority: 2 },
    { name: "Optimal elevator selection", priority: 2 },
    { name: "Emergency stop button", priority: 2 },
    
    // Nice to have
    { name: "Display current floor", priority: 3 },
    { name: "Destination dispatch system", priority: 3 },
    { name: "Weight sensor", priority: 3 },
    
    // Defer
    { name: "Maintenance mode", priority: 4 },
    { name: "Analytics dashboard", priority: 4 },
    { name: "Voice announcements", priority: 4 },
];
 
// ================================================
// INCREMENT 1: Walking Skeleton (Priority 1)
// "Single elevator responds to button press"
// ================================================
 
enum ElevatorState {
    IDLE = 'IDLE',
    MOVING_UP = 'MOVING_UP',
    MOVING_DOWN = 'MOVING_DOWN',
    DOORS_OPEN = 'DOORS_OPEN'
}
 
class Elevator {
    private currentFloor: number = 1;
    private state: ElevatorState = ElevatorState.IDLE;
    private destinationFloors: number[] = [];
    
    getCurrentFloor(): number { return this.currentFloor; }
    getState(): ElevatorState { return this.state; }
    
    requestFloor(floor: number): void {
        if (floor === this.currentFloor) {
            this.openDoors();
            return;
        }
        
        if (!this.destinationFloors.includes(floor)) {
            this.destinationFloors.push(floor);
            this.destinationFloors.sort((a, b) => a - b);
        }
        
        this.processNextDestination();
    }
    
    private processNextDestination(): void {
        if (this.destinationFloors.length === 0) {
            this.state = ElevatorState.IDLE;
            return;
        }
        
        const nextFloor = this.getNextDestination();
        
        if (nextFloor > this.currentFloor) {
            this.moveUp();
        } else if (nextFloor < this.currentFloor) {
            this.moveDown();
        }
    }
    
    private getNextDestination(): number {
        // Simple: go to closest
        return this.destinationFloors[0];
    }
    
    private moveUp(): void {
        this.state = ElevatorState.MOVING_UP;
        // In real system, this would be async
        this.currentFloor++;
        this.checkArrival();
    }
    
    private moveDown(): void {
        this.state = ElevatorState.MOVING_DOWN;
        this.currentFloor--;
        this.checkArrival();
    }
    
    private checkArrival(): void {
        if (this.destinationFloors.includes(this.currentFloor)) {
            this.destinationFloors = this.destinationFloors.filter(
                f => f !== this.currentFloor
            );
            this.openDoors();
        } else {
            this.processNextDestination();
        }
    }
    
    private openDoors(): void {
        this.state = ElevatorState.DOORS_OPEN;
        // Doors auto-close after delay
        setTimeout(() => this.closeDoors(), 3000);
    }
    
    private closeDoors(): void {
        this.processNextDestination();
    }
}
 
// ✅ INCREMENT 1 COMPLETE
// Can demo: Single elevator moving between floors
// Test: Request floors, verify arrival
 
// ================================================
// INCREMENT 2: Multiple Elevators (Priority 2)
// ================================================
 
class ElevatorController {
    private elevators: Elevator[] = [];
    
    constructor(elevatorCount: number) {
        for (let i = 0; i < elevatorCount; i++) {
            this.elevators.push(new Elevator());
        }
    }
    
    requestElevator(fromFloor: number): void {
        const bestElevator = this.selectBestElevator(fromFloor);
        bestElevator.requestFloor(fromFloor);
    }
    
    private selectBestElevator(targetFloor: number): Elevator {
        // Simple: select closest idle elevator, or closest overall
        let bestElevator = this.elevators[0];
        let bestDistance = Math.abs(
            bestElevator.getCurrentFloor() - targetFloor
        );
        
        for (const elevator of this.elevators) {
            const distance = Math.abs(elevator.getCurrentFloor() - targetFloor);
            
            // Prefer idle elevators
            if (elevator.getState() === ElevatorState.IDLE && 
                distance <= bestDistance) {
                bestElevator = elevator;
                bestDistance = distance;
            }
        }
        
        return bestElevator;
    }
}
 
// ✅ INCREMENT 2 COMPLETE
// Can demo: Multiple elevators, basic selection
// Builds on increment 1
 
// ================================================
// INCREMENT 3: Optimal Selection (Priority 2)
// ================================================
 
class SmartElevatorController extends ElevatorController {
    // Override selection with smarter algorithm
    private selectBestElevator(targetFloor: number): Elevator {
        // SCAN algorithm: prefer elevators moving toward the target
        // Implementation details...
        return super.selectBestElevator(targetFloor);
    }
}
 
// ✅ INCREMENT 3 COMPLETE
// Enhanced selection algorithm
// Increment 1 & 2 still work
 
// Continue with priority 2, then 3...
// Priority 4 items are stubbed or mentioned but not implemented

Maintaining a Working System at Every Step

The key discipline of incremental development is ensuring the system works after every change. This requires deliberate practices:

The Green-Bar Rule:

After every increment:

All existing tests still pass (no regressions)
New tests for the increment pass
The system can be demonstrated

If any of these fail, you haven't completed the increment—you've introduced a bug.

Techniques for Maintaining Working State:

Working System Practices

•Small commits — Each commit represents a working state; easy to revert if needed
•Feature flags — New code can exist but be disabled until ready
•Interface segregation — New features implement new interfaces, not modify existing ones
•Backward compatibility — Extend rather than change; deprecate rather than remove
•Continuous testing — Run tests after every meaningful change, not just at the end
•Demo frequently — If you can't demo it, it doesn't work

Maintaining Working State
TypeScript
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
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
// ================================================
// Example: Adding Features While Keeping System Working
// ================================================
 
// --- INITIAL WORKING STATE ---
 
interface PricingStrategy {
    calculatePrice(durationMinutes: number): number;
}
 
class FlatRatePricing implements PricingStrategy {
    constructor(private ratePerHour: number) {}
    
    calculatePrice(durationMinutes: number): number {
        const hours = Math.ceil(durationMinutes / 60);
        return hours * this.ratePerHour;
    }
}
 
class ParkingTicketService {
    constructor(private pricing: PricingStrategy) {}
    
    calculateFee(ticket: Ticket): number {
        const minutes = this.getDurationMinutes(ticket);
        return this.pricing.calculatePrice(minutes);
    }
    
    private getDurationMinutes(ticket: Ticket): number {
        const now = new Date();
        const entry = ticket.getEntryTime();
        return Math.floor((now.getTime() - entry.getTime()) / 60000);
    }
}
 
// ✅ Working: Flat rate pricing
 
// --- ADD TIME-OF-DAY PRICING (without breaking existing) ---
 
// New strategy implements same interface
class TimeOfDayPricing implements PricingStrategy {
    constructor(
        private dayRate: number,    // 6am - 6pm
        private nightRate: number   // 6pm - 6am
    ) {}
    
    calculatePrice(durationMinutes: number): number {
        // For simplicity, use current hour
        // Real implementation would prorate across time boundaries
        const hour = new Date().getHours();
        const rate = (hour >= 6 && hour < 18) ? this.dayRate : this.nightRate;
        const hours = Math.ceil(durationMinutes / 60);
        return hours * rate;
    }
}
 
// ✅ Working: Both FlatRatePricing AND TimeOfDayPricing work
// Existing code unchanged
// Existing tests still pass
 
// --- ADD VEHICLE-TYPE PRICING (extend interface carefully) ---
 
// Option 1: New interface (safest)
interface VehicleAwarePricing {
    calculatePrice(durationMinutes: number, vehicleType: VehicleType): number;
}
 
// Adapter to use new interface with existing service
class VehiclePricingAdapter implements PricingStrategy {
    constructor(
        private vehiclePricing: VehicleAwarePricing,
        private defaultVehicleType: VehicleType
    ) {}
    
    calculatePrice(durationMinutes: number): number {
        return this.vehiclePricing.calculatePrice(
            durationMinutes, 
            this.defaultVehicleType
        );
    }
}
 
// Option 2: Optional parameter (maintains backward compatibility)
interface PricingStrategyV2 {
    calculatePrice(durationMinutes: number, vehicleType?: VehicleType): number;
}
 
class VehicleAwareFlatRate implements PricingStrategyV2 {
    constructor(private rates: Map<VehicleType, number>) {}
    
    calculatePrice(durationMinutes: number, vehicleType?: VehicleType): number {
        const type = vehicleType || VehicleType.CAR; // Default maintains compatibility
        const rate = this.rates.get(type) || this.rates.get(VehicleType.CAR)!;
        const hours = Math.ceil(durationMinutes / 60);
        return hours * rate;
    }
}
 
// ✅ Working: All previous pricing strategies STILL WORK
// New vehicle-aware pricing also works
// No breaking changes
 
// --- FEATURE FLAG EXAMPLE ---
 
class ParkingSystem {
    private useNewPricingEngine: boolean;
    
    constructor(config: SystemConfig) {
        this.useNewPricingEngine = config.featureFlags.newPricingEngine;
    }
    
    calculateFee(ticket: Ticket): number {
        if (this.useNewPricingEngine) {
            // New code path
            return this.newPricingEngine.calculate(ticket);
        } else {
            // Old code path - known working
            return this.legacyPricing.calculateFee(ticket);
        }
    }
}
 
// ✅ Working: New code exists but is disabled by default
// Can enable for testing without affecting production
// If new code has bugs, flag off instantly

The Broken Window Effect

Once a system stops working ('I'll fix that later'), the pressure to keep it working disappears. Small breakages accumulate into large ones. Maintain the discipline: if you broke it, fix it before adding anything else. A working system is a prerequisite, not a goal.

Incremental Implementation in LLD Interviews

In LLD interviews, time is extremely limited. Incremental implementation becomes not just helpful but essential. You simply cannot implement everything, so you must maximize the value of what you do implement.

The Interview Reality:

45-60 minutes total
15-20 minutes for design discussion
25-35 minutes for implementation
Many classes, limited time per class

The Strategy: Core Flow First

Identify the core user flow — The primary use case the system must handle
Implement the minimal path through that flow — Happy path only, minimal validation
Demonstrate it works — Walk through the code, trace execution
Extend with secondary flows — If time permits
Acknowledge what's missing — Show awareness of gaps

Interview Incremental Strategy
TypeScript
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
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
// ================================================
// Interview: Design a Parking Lot System (35 min implementation)
// ================================================
 
// MINUTE 0-2: Identify core flow
// "The core flow is: Vehicle enters → Gets ticket → Parks → 
//  Pays → Exits. I'll implement this first."
 
// MINUTE 2-7: Core entities (minimal)
enum VehicleType { CAR, MOTORCYCLE, TRUCK }
enum SpotSize { COMPACT, REGULAR, LARGE }
 
class Vehicle {
    constructor(
        private licensePlate: string,
        private type: VehicleType
    ) {}
    
    getLicensePlate(): string { return this.licensePlate; }
    getType(): VehicleType { return this.type; }
}
 
class ParkingSpot {
    private vehicle: Vehicle | null = null;
    
    constructor(
        private id: string,
        private size: SpotSize
    ) {}
    
    isAvailable(): boolean { return this.vehicle === null; }
    park(vehicle: Vehicle): void { this.vehicle = vehicle; }
    vacate(): void { this.vehicle = null; }
    canFit(vehicleType: VehicleType): boolean {
        // Simple mapping
        if (vehicleType === VehicleType.MOTORCYCLE) return true;
        if (vehicleType === VehicleType.CAR) return this.size !== SpotSize.COMPACT;
        return this.size === SpotSize.LARGE;
    }
}
 
class Ticket {
    private exitTime: Date | null = null;
    
    constructor(
        private id: string,
        private vehicle: Vehicle,
        private spot: ParkingSpot,
        private entryTime: Date = new Date()
    ) {}
    
    getId(): string { return this.id; }
    getVehicle(): Vehicle { return this.vehicle; }
    getSpot(): ParkingSpot { return this.spot; }
    getEntryTime(): Date { return this.entryTime; }
    getExitTime(): Date | null { return this.exitTime; }
    
    markExit(): void { this.exitTime = new Date(); }
}
 
// MINUTE 7-15: Core service (parking flow)
class ParkingLot {
    private spots: ParkingSpot[] = [];
    private activeTickets: Map<string, Ticket> = new Map();
    private hourlyRate: number;
    
    constructor(hourlyRate: number) {
        this.hourlyRate = hourlyRate;
        this.initializeSpots();
    }
    
    private initializeSpots(): void {
        // Create spots - simplified
        for (let i = 0; i < 50; i++) {
            this.spots.push(new ParkingSpot(`C${i}`, SpotSize.COMPACT));
        }
        for (let i = 0; i < 100; i++) {
            this.spots.push(new ParkingSpot(`R${i}`, SpotSize.REGULAR));
        }
        for (let i = 0; i < 20; i++) {
            this.spots.push(new ParkingSpot(`L${i}`, SpotSize.LARGE));
        }
    }
    
    // Core operation 1: Entry
    enter(vehicle: Vehicle): Ticket {
        const spot = this.findAvailableSpot(vehicle.getType());
        if (!spot) {
            throw new Error("No available spots");
        }
        
        spot.park(vehicle);
        const ticket = new Ticket(
            `TKT-${Date.now()}`,
            vehicle,
            spot
        );
        
        this.activeTickets.set(ticket.getId(), ticket);
        return ticket;
    }
    
    private findAvailableSpot(vehicleType: VehicleType): ParkingSpot | null {
        return this.spots.find(spot => 
            spot.isAvailable() && spot.canFit(vehicleType)
        ) || null;
    }
    
    // Core operation 2: Calculate fee
    calculateFee(ticketId: string): number {
        const ticket = this.activeTickets.get(ticketId);
        if (!ticket) throw new Error("Ticket not found");
        
        const now = new Date();
        const hours = Math.ceil(
            (now.getTime() - ticket.getEntryTime().getTime()) / (1000 * 60 * 60)
        );
        
        return hours * this.hourlyRate;
    }
    
    // Core operation 3: Exit
    exit(ticketId: string, paymentAmount: number): void {
        const ticket = this.activeTickets.get(ticketId);
        if (!ticket) throw new Error("Ticket not found");
        
        const fee = this.calculateFee(ticketId);
        if (paymentAmount < fee) {
            throw new Error(`Insufficient payment. Required: ${fee}`);
        }
        
        ticket.markExit();
        ticket.getSpot().vacate();
        this.activeTickets.delete(ticketId);
    }
}
 
// ✅ MINUTE 15: CORE FLOW COMPLETE
// Say: "Let me walk you through the core flow..."
// Trace: Vehicle enters → Spot assigned → Ticket issued → 
//        Fee calculated → Payment processed → Spot freed
 
// MINUTE 15-20: Add one enhancement (if time)
// "Now I'll add multiple floors..."
 
class ParkingFloor {
    private spots: ParkingSpot[] = [];
    
    constructor(
        private floorNumber: number,
        compactCount: number,
        regularCount: number,
        largeCount: number
    ) {
        this.initializeSpots(compactCount, regularCount, largeCount);
    }
    
    private initializeSpots(compact: number, regular: number, large: number): void {
        const prefix = `F${this.floorNumber}`;
        for (let i = 0; i < compact; i++) {
            this.spots.push(new ParkingSpot(`${prefix}-C${i}`, SpotSize.COMPACT));
        }
        for (let i = 0; i < regular; i++) {
            this.spots.push(new ParkingSpot(`${prefix}-R${i}`, SpotSize.REGULAR));
        }
        for (let i = 0; i < large; i++) {
            this.spots.push(new ParkingSpot(`${prefix}-L${i}`, SpotSize.LARGE));
        }
    }
    
    findAvailableSpot(vehicleType: VehicleType): ParkingSpot | null {
        return this.spots.find(spot => 
            spot.isAvailable() && spot.canFit(vehicleType)
        ) || null;
    }
}
 
// ✅ MINUTE 20: Enhanced with floors
 
// MINUTE 20-25: Payment system abstraction
interface PaymentProcessor {
    process(amount: number, method: PaymentMethod): PaymentResult;
}
 
class CashPayment implements PaymentProcessor {
    process(amount: number, method: PaymentMethod): PaymentResult {
        // Cash always succeeds
        return { success: true, transactionId: `CASH-${Date.now()}` };
    }
}
 
class CardPayment implements PaymentProcessor {
    process(amount: number, method: PaymentMethod): PaymentResult {
        // Would call payment gateway
        return { success: true, transactionId: `CARD-${Date.now()}` };
    }
}
 
// ✅ MINUTE 25: Payment abstraction in place
 
// MINUTE 25-30: Walk through, answer questions
// "What I haven't implemented but would in production:
// - Multiple lot management
// - Reserved spots
// - Subscription pricing
// - Real-time spot display
// - Historical reporting
// These would follow the same patterns I've shown."
 
// MINUTE 30-35: Extension based on interviewer questions
// "You asked about peak pricing? Here's how I would add that..."
 
interface PricingStrategy {
    calculateFee(durationMinutes: number, vehicleType: VehicleType): number;
}
 
class PeakPricing implements PricingStrategy {
    constructor(
        private baseRate: number,
        private peakMultiplier: number,
        private peakHours: { start: number; end: number }
    ) {}
    
    calculateFee(durationMinutes: number, vehicleType: VehicleType): number {
        const currentHour = new Date().getHours();
        const isPeak = currentHour >= this.peakHours.start && 
                       currentHour < this.peakHours.end;
        
        const rate = isPeak ? this.baseRate * this.peakMultiplier : this.baseRate;
        return Math.ceil(durationMinutes / 60) * rate;
    }
}
 
// ✅ MINUTE 35: Demonstrated extensibility

The Demonstration Moment

After implementing the core flow, pause and walk through it. Say: 'Let me trace through what happens when a vehicle enters...' and explain each step. This proves your code works, shows you can reason about it, and gives the interviewer confidence that the rest would work too.

Common Incremental Implementation Patterns

Several patterns emerge repeatedly in incremental implementation. Recognizing them accelerates your work.

Pattern 1: Happy Path First

Implement the successful case before any error handling. A system that works for valid inputs is infinitely more valuable than one that rejects invalid inputs but doesn't process valid ones.

Happy Path First
TypeScript
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
// INCREMENT 1: Happy path only
class OrderService {
    placeOrder(order: Order): OrderResult {
        // Assume valid input, sufficient inventory, working payment
        this.inventory.reserve(order.items);
        this.payment.charge(order.total);
        return { success: true, orderId: order.id };
    }
}
 
// INCREMENT 2: Add validation
class OrderServiceV2 {
    placeOrder(order: Order): OrderResult {
        // Validation layer
        if (!order.items.length) {
            throw new Error("Order must have items");
        }
        if (order.total <= 0) {
            throw new Error("Order total must be positive");
        }
        
        // Happy path (unchanged)
        this.inventory.reserve(order.items);
        this.payment.charge(order.total);
        return { success: true, orderId: order.id };
    }
}
 
// INCREMENT 3: Add error recovery
class OrderServiceV3 {
    placeOrder(order: Order): OrderResult {
        // Validation
        this.validate(order);
        
        // Try to reserve inventory
        const reserved = this.inventory.reserve(order.items);
        if (!reserved) {
            throw new InsufficientInventoryError(order.items);
        }
        
        // Try to charge, rollback on failure
        try {
            this.payment.charge(order.total);
        } catch (error) {
            this.inventory.release(order.items); // Rollback
            throw new PaymentFailedError(error);
        }
        
        return { success: true, orderId: order.id };
    }
}

Pattern 2: Stub and Replace

Create placeholder implementations that allow the system to work, then replace them with real implementations incrementally.

Stub and Replace
TypeScript
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
// INCREMENT 1: Stub implementations
class StubEmailService implements EmailService {
    async send(to: string, subject: string, body: string): Promise<void> {
        console.log(`[EMAIL STUB] To: ${to}, Subject: ${subject}`);
        // Does nothing - but system works!
    }
}
 
class StubPaymentGateway implements PaymentGateway {
    async charge(amount: number): Promise<PaymentResult> {
        console.log(`[PAYMENT STUB] Charging ${amount}`);
        return { success: true, transactionId: 'STUB-123' };
    }
}
 
// System works end-to-end with stubs
const service = new OrderService(
    new StubEmailService(),
    new StubPaymentGateway()
);
 
// INCREMENT 2: Replace email with real
const serviceV2 = new OrderService(
    new SendGridEmailService(apiKey),  // Real
    new StubPaymentGateway()           // Still stub
);
 
// INCREMENT 3: Replace payment with real
const serviceV3 = new OrderService(
    new SendGridEmailService(apiKey),
    new StripePaymentGateway(stripeKey)  // Real
);

Pattern 3: Single Variant First

When there are multiple similar classes (vehicle types, payment methods, notification channels), implement one fully, then replicate the pattern.

Single Variant First
TypeScript
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
// INCREMENT 1: Implement Car only
class Car extends Vehicle {
    constructor(licensePlate: string) {
        super(licensePlate, VehicleType.CAR);
    }
    
    getRequiredSpotSize(): SpotSize { return SpotSize.REGULAR; }
    getHourlyRate(): number { return 10; }
}
 
// System works with cars only
const parkingLot = new ParkingLot();
parkingLot.enter(new Car("ABC-123")); // Works!
 
// INCREMENT 2: Add motorcycle (copy pattern from Car)
class Motorcycle extends Vehicle {
    constructor(licensePlate: string) {
        super(licensePlate, VehicleType.MOTORCYCLE);
    }
    
    getRequiredSpotSize(): SpotSize { return SpotSize.COMPACT; }
    getHourlyRate(): number { return 5; }
}
 
// INCREMENT 3: Add truck (copy pattern from Car)  
class Truck extends Vehicle {
    constructor(licensePlate: string) {
        super(licensePlate, VehicleType.TRUCK);
    }
    
    getRequiredSpotSize(): SpotSize { return SpotSize.LARGE; }
    getHourlyRate(): number { return 20; }
}
 
// In an interview, say:
// "Motorcycle and Truck follow the same pattern as Car.
//  I've implemented Car fully; the others are templates."

Pattern Recognition Speeds You Up

Once you recognize 'this is a stub-and-replace situation' or 'this is a single-variant-first case,' you can apply the pattern without thinking through first principles. These patterns become muscle memory with practice.

Summary: Incremental Implementation

We've explored the philosophy and practice of incremental implementation. Here are the essential principles:

Key Takeaways

•Working software at every step — Never let the system be in a broken state
•Vertical slices over horizontal layers — Complete user flows before infrastructure
•Prioritize by value and risk — Core flow first, edge cases later
•Happy path before error handling — A system that works is better than one that rejects
•Stub and replace — Placeholders let you demonstrate the system before everything is real
•Single variant first — Implement one fully, then template the others
•Demonstrate frequently — If you can't trace through it, it doesn't work

Module Complete

Congratulations! You've completed the 'From Design to Code' module. You now have a comprehensive framework for translating UML designs to production code, determining implementation order, applying interface-first principles, and building incrementally. These skills combine to make you effective in both interviews and real-world software development. Practice them deliberately, and they'll become second nature.

Module Summary:

This module covered the complete journey from design to code:

Translating UML to Code — Systematic mapping of class diagrams, relationships, and multiplicity to language constructs
Class Implementation Order — Dependency analysis and tier-based implementation for maximum productivity
Interface First, Implementation Second — Defining contracts before details for flexibility and testability
Incremental Implementation — Building working systems piece by piece with continuous validation

With these skills, you can confidently approach any LLD problem—whether in an interview or a production codebase—and systematically transform designs into high-quality, working code.