YAGNI (You Aren't Gonna Need It) in LLD - Practice Problems & Coding Challenges

Challenge - 5 Problems

🧠 Conceptual

intermediate

Identifying YAGNI Violations in Feature Planning

You are designing a simple note-taking app. The team suggests adding a complex tagging system with nested tags and tag analytics before the app's first release. Which statement best reflects the YAGNI principle?

A Implement the tagging system now to avoid rework later.

B Design the app assuming the tagging system will be needed soon.

C Add the tagging system partially to test user interest.

D Skip the tagging system until users request it or it becomes necessary.

💡 Hint

YAGNI encourages avoiding building features before they are truly needed.

YAGNI means you should not add functionality until it is necessary. Adding complex features early can waste time and resources.

❓ Architecture

intermediate

Applying YAGNI in System Architecture Decisions

You are designing a web service expected to handle 100 requests per second initially. The team suggests building a microservices architecture with complex service discovery and load balancing from the start. According to YAGNI, what is the best approach?

A Build the microservices architecture now to prepare for future growth.

B Implement microservices but disable service discovery until needed.

C Start with a simple monolithic design and refactor if scaling is needed.

D Design the system with microservices but use a single database for simplicity.

💡 Hint

Consider starting simple and only adding complexity when justified.

YAGNI advises against premature optimization or over-engineering. Starting simple reduces complexity and development time.

❓ scaling

advanced

Estimating Capacity Without Over-Engineering

Your team plans to build a chat application. They want to provision servers to handle 1 million concurrent users immediately, but current projections estimate only 10,000 users in the first year. How does YAGNI guide your capacity planning?

A Provision servers for 500,000 users as a compromise.

B Provision capacity for 10,000 users and scale up as demand grows.

C Provision servers for 1 million users now to avoid downtime later.

D Use cloud auto-scaling but configure it for maximum capacity upfront.

💡 Hint

Think about starting with what is needed, not what might be needed.

YAGNI suggests not preparing for unlikely future scenarios prematurely. Start with realistic capacity and scale as needed.

❓ tradeoff

advanced

Balancing YAGNI with Future-Proofing

You are designing a payment processing system. The team debates whether to support multiple currencies now or add it later. Supporting multiple currencies adds complexity but may attract more users in the future. How should YAGNI influence this decision?

A Design the system with multi-currency in mind but implement only one currency initially.

B Build the system for one currency and add multi-currency support only if needed.

C Implement multi-currency support now to avoid costly refactoring later.

D Ignore multi-currency support entirely as it is not needed now.

💡 Hint

Consider designing for flexibility without adding unnecessary features immediately.

YAGNI encourages avoiding unnecessary features but does not forbid designing for easy extension later.

❓ component

expert

Identifying YAGNI Violations in Low-Level Design

Examine the following class design for a user profile component. Which part violates YAGNI?

class UserProfile {
  String username;
  String email;
  String phoneNumber;
  String address;
  Map socialMediaLinks; // planned for future use
  List favoriteGenres; // planned for future use

  void updateEmail(String newEmail) { /* ... */ }
  void updatePhoneNumber(String newPhone) { /* ... */ }
  // Methods for socialMediaLinks and favoriteGenres not implemented yet
}

LLD

class UserProfile {
  String username;
  String email;
  String phoneNumber;
  String address;
  Map<String, String> socialMediaLinks; // planned for future use
  List<String> favoriteGenres; // planned for future use

  void updateEmail(String newEmail) { /* ... */ }
  void updatePhoneNumber(String newPhone) { /* ... */ }
  // Methods for socialMediaLinks and favoriteGenres not implemented yet
}

A Including socialMediaLinks and favoriteGenres fields before they are needed.

B Not implementing update methods for socialMediaLinks and favoriteGenres yet.

C Having updateEmail and updatePhoneNumber methods implemented.

D Including username, email, phoneNumber, and address fields.

💡 Hint

YAGNI warns against adding unused features or data structures prematurely.

Adding fields for future features that are not yet needed or implemented violates YAGNI by increasing complexity unnecessarily.

Practice

1. What does the YAGNI principle primarily encourage in system design?

easy

A. Build only features you currently need

B. Plan and build all possible future features

C. Add complex layers for scalability upfront

D. Write extra code for potential edge cases

Solution

1. Step 1: Understand YAGNI meaning

   YAGNI stands for "You Aren't Gonna Need It" and advises to avoid building features before they are necessary.

2. Step 2: Match principle to options

   Build only features you currently need matches the idea of building only what is needed now, while others suggest building for future or complexity.

3. Final Answer:

   Build only features you currently need -> Option A

4. Quick Check:

   YAGNI = Build only what you need now [OK]

Hint: YAGNI means avoid future guesswork, build now only [OK]

Common Mistakes:

• Thinking YAGNI means planning for all future needs
• Confusing YAGNI with over-engineering
• Assuming YAGNI discourages any planning

2. Which of the following is the correct way to apply YAGNI when designing a new feature in a system?

easy

A. Add detailed logging for every possible error before deployment

B. Design the database schema to handle all future data types

C. Write unit tests for features you plan to add later

D. Implement only the core functionality needed for the feature now

Solution

1. Step 1: Identify core YAGNI practice

   YAGNI advises to implement only what is necessary now, avoiding premature additions.

2. Step 2: Evaluate options for current need focus

   Implement only the core functionality needed for the feature now focuses on core functionality now, while others add future or unnecessary work.

3. Final Answer:

   Implement only the core functionality needed for the feature now -> Option D

4. Quick Check:

   YAGNI = Build core now, skip extras [OK]

Hint: Focus on core feature first, skip extras [OK]

Common Mistakes:

• Adding features or tests for future needs
• Over-engineering database for unknown data
• Writing unnecessary logs before real errors occur

3. Consider this scenario: A team adds a caching layer anticipating high traffic, but the system never reaches that load. What does this violate in terms of YAGNI?

medium

A. They avoided unnecessary complexity

B. They followed YAGNI by preparing for future needs

C. They built a feature they didn't need yet

D. They simplified the system by adding cache

Solution

1. Step 1: Analyze the caching layer addition

   The team added caching before it was needed, anticipating future load.

2. Step 2: Relate to YAGNI principle

   YAGNI discourages building features before they are actually needed, so this is a violation.

3. Final Answer:

   They built a feature they didn't need yet -> Option C

4. Quick Check:

   YAGNI violation = building unneeded features [OK]

Hint: Building features before need breaks YAGNI [OK]

Common Mistakes:

• Thinking preparing for future is YAGNI
• Confusing simplification with premature optimization
• Assuming caching always simplifies system

4. A developer added a complex permission system anticipating many user roles, but the product currently has only one role. What is the main issue here related to YAGNI?

medium

A. The developer ignored YAGNI by adding unnecessary complexity

B. The permission system is too simple for current needs

C. The system is scalable and follows YAGNI

D. The product requires multiple roles immediately

Solution

1. Step 1: Identify the developer's action

   The developer added a complex system for roles not currently needed.

2. Step 2: Connect to YAGNI principle

   YAGNI advises against adding complexity before it's necessary, so this is a violation.

3. Final Answer:

   The developer ignored YAGNI by adding unnecessary complexity -> Option A

4. Quick Check:

   Unneeded complexity violates YAGNI [OK]

Hint: Avoid complexity until it's truly needed [OK]

Common Mistakes:

• Assuming scalability means following YAGNI
• Believing all future roles must be planned now
• Confusing simple with insufficient

5. You are designing a messaging system. You consider adding encryption support now, but the current users do not require it. According to YAGNI, what should you do?

hard

A. Implement encryption now to avoid future rework

B. Skip encryption for now and add it when users need it

C. Design the system assuming all messages are encrypted

D. Build a complex key management system upfront

Solution

1. Step 1: Understand current user needs

   Users do not require encryption now, so it is not immediately necessary.

2. Step 2: Apply YAGNI principle to design decision

   YAGNI advises to avoid building features before they are needed, so skip encryption now.

3. Final Answer:

   Skip encryption for now and add it when users need it -> Option B

4. Quick Check:

   YAGNI = build features only when needed [OK]

Hint: Add features only when users actually need them [OK]

Common Mistakes:

• Building features just to avoid future work
• Assuming all users need encryption immediately
• Over-engineering system upfront