My Journey: From DRY-Obsessed to Clarity-First

When I started out as a developer, I tried to follow every best practice I could find. One of the first and the loudest was:

“Don’t Repeat Yourself.”

So I did what I thought was right:

• Extracted helper functions for similar code

• Created shared utilities

• Built abstract base classes

• Wrapped everything I could into reusable methods

At first, it felt like I was being efficient. My code was DRY, clean, and professional.

But over time, I started to feel the pain:

• Code became harder to understand

• Changes in one place broke things in others

• I couldn’t understand my own abstractions weeks later

That’s when I realized:

Being DRY isn’t the goal. Being clear is.

What DRY Really Means

The original DRY principle comes from The Pragmatic Programmer:

“Every piece of knowledge must have a single, unambiguous, authoritative representation”

The keyword here is knowledge — not necessarily code.

But in practice, DRY gets misapplied. Developers (including me) start removing every repeated line even when that repetition helps readability.

When DRY Hurts More Than It Helps

Here are some patterns I now try to avoid, based on painful experience.

1. Over-Abstraction

# utils.py
def handle_status(obj, is_active=False, should_log=False):
    ...

You save a few lines by reusing the function but now, nobody can tell what is_active or should_log means without digging into the helper.

Sometimes, copying those 4–5 lines is better than hiding them behind flags.

2. Shared Logic for Different Contexts

Just because two blocks of code look the same doesn’t mean they should be shared.

Example: You have two functions that process different types of files — CSV and JSON. Initially, both perform similar validation, so you extract a shared validate_data() function.

def validate_data(data):
    if not data:
        raise ValueError("No data provided")
    if len(data) > 1000:
        raise ValueError("Data too large")
    return True

def process_csv(file):
    data = read_csv(file)
    validate_data(data)

def process_json(file):
    data = read_json(file)
    validate_data(data)

Months later, the JSON processing needs to validate the presence of a special key, but CSV does not. You modify validate_data() to include that check:

def validate_data(data, is_json=False):
    if not data:
        raise ValueError("No data provided")
    if len(data) > 1000:
        raise ValueError("Data too large")
    if is_json and "required_key" not in data:
        raise ValueError("Missing required_key in JSON data")
    return True

Now, the CSV validation call either needs to explicitly pass is_json=False everywhere, or risk unexpected behavior and the function grows more complex.

Better approach:

Keep validation separate and explicit:

def validate_csv_data(data):
    if not data:
        raise ValueError("No data provided")
    if len(data) > 1000:
        raise ValueError("Data too large")
    return True

def validate_json_data(data):
    if not data:
        raise ValueError("No data provided")
    if len(data) > 1000:
        raise ValueError("Data too large")
    if "required_key" not in data:
        raise ValueError("Missing required_key in JSON data")
    return True

This duplication is clearer, safer to maintain, and avoids accidental breakage.

Takeaway:
Even if two pieces of logic look the same initially, differences in their context often mean they need separate handling. Shared functions with flags can become a source of bugs.

3. Reuse That’s Never Actually Reused

Ever extracted a helper function thinking you’d use it again?

I’ve done it. And then never reused it. Now I have:

• An extra file to maintain

• A function no one understands

• Indirection that adds no value

Sometimes, copying and pasting is the right decision.

When Repetition Is the Right Choice

Use repetition instead of abstraction in these cases:

• The repeated code is short, simple, and self-explanatory

• The logic exists in different domains or contexts

• The code is still evolving or experimental

• The abstraction would need flags, switches, or multiple conditionals

• The duplication makes each block easier to read in isolation

• The team (or future you) can understand the duplicated code faster than tracing a helper

• You’re not 100% sure if the similarity is conceptual or just superficial

• Changing one instance shouldn’t affect the other

Better Than DRY: AHA, DAMP, and WET

Here are a few other principles I now follow more closely:

• AHA — Avoid Hasty Abstractions

• WET — Write Everything Twice (then refactor later)

• DAMP — Descriptive And Meaningful Phrases

These emphasize clarity, intention, and timing over premature optimization.

Real-World Example

Before (DRY attempt):

def update_status(obj, active=False):
    obj.status = 'active' if active else 'inactive'
    obj.save()

Used in two places, but with edge cases that needed special handling. Eventually, it broke things.

After (clear duplication):

# project_view.py
project.status = 'active'
project.save()

# organization_view.py
org.status = 'inactive'
org.save()

Readable. Maintainable. Safe.

🧘 Final Thoughts

Yes, DRY is important. But it’s not a rule — it’s a guideline. If applying it makes your code harder to read or change, then it’s not helping.

Be DRY when it makes things clearer.

Be repetitive when it makes things obvious.

If I could tell my beginner self one thing, it would be:

“Write code for the next person who reads it — even if that’s future you.”