If:Else Logic and Complexity – Hiding the Pea.

I was recently confronted with an interesting conundrum when writing a complex data pipeline. It was an interesting problem that arose from my quest to reduce complexity in part of the design, which found itself creeping into another part, re-enforcing the classic idea of whether you can really make the complexity pea go away, or if you simply shuffle the pea somewhere else to hide it.

It’s really a very simple and common problem when designing data-intensive applications. This was the obvious problem of …

• I need to run these very similar “snapshot” concepts (~5 of them).
• Where should I move the complexity, keep the switching logic separate, or increase it by moving pieces together?

This is one small basic piece of logic, more or less, and it just struck me as wrong. I mean sure, I could shove the logic in ChatGPT and ask it to simplify my logic … but it’s more than that. It’s about …

• readability
• debugability
• how did I get here in the first place?

In one sense it’s good to locate all logic for a “thing” in one place rather than spreading it out over files and components. If you have complex logic because the business requirements simply call for it … how do you keep reasonable? I mean you could refactor your code so that the logic for each thing is gone and you just deal with different modules or pipelines.

But that’s a trade-off, now I might be running extra Airflow DAGs and reproducing a bunch of logic and end up with “more code” in the end … which leads to the potential for more bugs, problems, and reactors etc.

Wrapping up so many if:else statements into a single method or function means you better be good at unit testing, to ensure you doing what you want to do. It’s easy when nesting if:else statements to do things you don’t mean to do. At a certain point, it simply gets harder to say what you mean.

Let’s take this question and answer about nested if:else logic from Reddit.

I pretty much agree with this assessment. If you end up working yourself into a corner with if:else logic you should probably stop and take some time to consider your overall design and approach to the problem.

In my case, and at my age, I have lost my love for OOP over the years, it breeds more evils than it fixes … but maybe simply just a redesign with more encapsulated and specific logic for certain use cases, instead of shoving everything in one spot.

What are your thoughts? How do you breakdown if:else complexity and logic so it doesn’t get crazy? Do you use certain design patterns? At what point do you know you need to do something?