Big reusable things are complex

Conditionals attract bugs

Conditionals tend to gather mass and live inside “reusable” components.

Rich Hickey says that conditionals complect the "why" with the rest of the program.

Big reusable things are complex. They pull in concerns from various places into a single place, and then twist them all together such that they must all be considered together.

Think about the gnarliest parts of a codebase you work on. When you encounter a conditional, and you need to make a change, are you going to refactor the conditional out? Absolutely not. You’re going to add another condition. This conditional is going to grow and grow until its mass attracts bugs the size of the bug from Men in Black. Where does this conditional live? Is it well named, or is it named so generically such as to be opaque and unhelpful?

Imagine, instead, more, smaller objects. They aren’t each reusable - they each do one thing. They are much more aptly named, which aids readability. It’s okay to add another one, because they aren’t all twisted together. They’re neat and organized.

Rather than building a single, large, reusable thing, build smaller objects and consider something like the abstract factory pattern.