DRY, KISS, and YAGNI Principles

# CHAPTER 8

DRY, KISS, and YAGNI Principles #

1. Introduction #

2. Learning Objectives #

• Define and apply the DRY principle to eliminate duplicate code.

• Understand the danger of copy-paste programming and maintenance nightmares.

• Apply the KISS principle to favor simple, readable solutions over complex architectures.

• Utilize the YAGNI principle to prevent premature optimization and overengineering.

• Balance reusability with simplicity.

3. DRY (Don’t Repeat Yourself) #

• The Problem: A developer needs to calculate tax. They write the formula in the CartController. Later, they need it in the InvoiceService. They copy and paste the formula. Next year, the government changes the tax rate. The developer updates the Cart, but forgets the Invoice. The system is now mathematically corrupt.

• The Solution: Extract the formula into a single TaxCalculator class. Both the Cart and the Invoice call this one class. If the law changes, you update the code in exactly *one* place.

4. KISS (Keep It Simple, Stupid) #

• The Problem: Developers love building complex things. To solve a simple problem (like parsing a CSV file), a developer might build a massive, multi-layered, abstract factory framework with 12 interfaces.

• The Solution: Does a simple while loop work? Use the while loop. Do not introduce Design Patterns, complex inheritance, or new frameworks unless the problem is so complex that a simple solution is no longer viable. Complexity is a liability, not an asset.

5. YAGNI (You Aren’t Gonna Need It) #

• The Problem (Overengineering): The Product Owner asks for a simple blog page. The developer spends 3 weeks building a highly scalable, multi-tenant caching layer because "we might have 10 million users next year."

• The Reality: 90% of the features you build "just in case" are never used. They become dead code that the team has to maintain forever. It wastes money and slows down development.

• The Solution: Build exactly what is required to fulfill today's User Story. If you hit 10 million users next year, refactor the code *next year*.

6. The Balancing Act #

• Trying to make code perfectly DRY can sometimes result in abstractions so complex that it violates KISS.

• *Rule of Thumb (The Rule of Three):* Do not apply DRY the very first time you copy code. Wait until you have written the exact same code *three* times. Then, the pattern is obvious, and it is time to extract it into a shared function. This prevents premature, incorrect abstractions.

7. Diagrams/Visual Suggestions #

[ The Request ] -> "Build a login form." (Estimate: 2 Days)

[ The Overengineering (YAGNI Violation) ]
- Setup multi-region database replication (Just in case).
- Build biometric scanning interface (Just in case).
- Implement blockchain token auth (Just in case).
(Actual Delivery: 4 Weeks. The startup ran out of money and died).

8. Best Practices #

• Delete Dead Code: If you built something violating YAGNI 2 years ago, and it is still sitting unused in the codebase, delete it immediately. It is polluting your search results and confusing new developers. Version Control has a backup if you ever need it.

9. Common Mistakes #

• The Wrong Abstraction (Forced DRY): Two functions happen to have 5 lines of identical code *by coincidence*, but they represent entirely different business rules (e.g., calculating a user's age vs calculating a server's uptime). A developer forces them to share a function to be "DRY." When the business rules inevitably diverge, the shared function becomes a tangled mess of if/else statements. Duplication is cheaper than the wrong abstraction.

10. Mini Project: Refactor for DRY #

function printAdminReport($users) {
    echo "<h1>Admin Report</h1>";
    foreach($users as $u) { echo "<li>" . $u->name . "</li>"; }
}

function printManagerReport($users) {
    echo "<h1>Manager Report</h1>";
    foreach($users as $u) { echo "<li>" . $u->name . "</li>"; }
}

*After (Applying DRY):*

function printReport(string $title, array $users) {
    echo "<h1>{$title}</h1>";
    foreach($users as $user) { 
        echo "<li>{$user->name}</li>"; 
    }
}
// Usage: printReport("Admin Report", $users);

11. Practice Exercises #

1. 1. Define the YAGNI principle. Why is building features "just in case we need them later" a massive financial waste for a software company?

1. 2. Explain the "Rule of Three" in relation to the DRY principle.

12. MCQs with Answers #

13. Interview Questions #

• Q: Explain a situation where "Duplication is cheaper than the wrong abstraction." When might forcing the DRY principle actually harm a codebase?

• Q: A junior developer spends a week building an elaborate caching mechanism for a database table that currently has only 50 rows, citing future scalability. As an architectural reviewer, how do you explain YAGNI to them?

• Q: How do the principles of KISS and YAGNI align directly with the Agile manifesto's focus on iterative, incremental delivery?

14. FAQs #

15. Summary #

16. Next Chapter Recommendation #