Welcome to this Website

Ever Written Something Like This?

if (condition) {
    doSomething();
} else {
    doSomethingElse();
}

It works. Problem solved.

But the problem isn’t today. It’s tomorrow.

IFs make change easy—once. Add enough IFs, and suddenly change isn’t so easy anymore. Nested conditions pile up, logic tangles, and the cost of change skyrockets.

IFs seem innocent, but they hide a deeper problem: they make your software harder to grow.

Software Becomes a ‘Code Monster’ One IF at a Time

IFs are sneaky.

At first, they feel like control. One small condition here, another there. But soon, your code resists you.

Nested IFs don’t scale—they collapse. You try to follow the flow, but duplication hides bugs. Every new feature fights back.

What once felt simple now feels fragile. IFs start as helpers but end as chaos.

Defusing the IF Strategy

If you’re here, you probably fall into one of these categories:

• “I have no idea, but I’d like to learn.”
  IFs make your code rigid and fragile. You’ve seen this happen firsthand.
• “Can a Strategy help?”
  You’ve read about "Clean IFs." You’ve told yourself, “I’ll refactor later.” But do you? And if you do, how?
• “IFs represent the duality of the universe.”
  “I don't see any problems. After all, at the assembly level, it's CMP all the way.“
• “This is all a scam.”
  You’re convinced programming without relying on IFs is impossible. Maybe. But what if it isn’t?

Whoever you are, welcome.

Let’s Be Clear

This isn’t about "no IFs ever."

It’s about this: if I can handle change without an IF, my code will be simpler and easier to grow.

For example, in the Diamond Kata I developed:

grep -rw 'if' . | wc -l
        0

Result? Zero. No IFs.

But the ultimate goal is to reduce the cost of change.

Reducing the number of IFs to zero is merely a consequence.

Try it: run the command in your project folder:

grep -rw 'if' . | wc -l

Do you use IFs as sparingly as you think? Or have they crept in quietly?

What Will You Find on This Site?

Over the years, I’ve learned this: developers love IFs.

Challenging IFs feels personal.

This site isn’t here to convince you. If you want to use IFs, go ahead. I prefer not.

Here, you’ll find:

• Projects where I avoided IFs to handle change.
  Compare the code with yours.
• Workshops showing how these projects evolved.
  Ask questions, see the process.

How to Defuse the IF Strategy?

Talking about avoiding IFs is easy. Doing it is harder.

Instead of debating, I focus on projects. Real code. Real results.

Polymorphism, maps, design patterns—there are many ways to replace IFs.

I’ve used a systematic method since 2005 to avoid IFs. It’s not magic, just a different way of thinking.

I’ll share that method soon, but this site isn’t about one approach. It’s about showing what’s possible.

Because seeing is believing.