What design pattern can be used for feature toggle spaghetti?

Question

The company that I work for has gone off the deep end with feature toggles-configuration keys that turn on/off particular behavior based on certain conditions. Martin Fowler actually refers to them as business toggles (http://martinfowler.com/bliki/FeatureToggle.html).

We have many clients all using the same service, but each wants slightly different behavior. Even worse, many want certain subgroups of their users to see different behavior. Thus, we use business toggles. The toggles have become a spaghetti ball of if/else logic that with occasionally unexpected interactions.

Are there any design patterns useful in managing a situation such as this?

Cheers!

Answer 1

• The switches should be run-time switches, not compile-time ones. The reason is, that switches should be operable without re-deployment.
• There are two possibilities to implement run-time conditional logic:
  1. if-then-else (or switch-case for multi-state switches)
  2. Polymorphy, which requires an object-oriented programming language.

I, personally, prefer to use plain if-then-else constructs, decorated with a comment saying TODO: Remove when feature has been tested. when applicable.

Keep in mind that every feature flag is a technical debt. Do not overuse them. I recommend against using them for business logic.

---

However, regarding your spaghetti ball of business toggles, I would recommend a refactoring.

• No function should have a nesting depth larger than two. If it has, split into multiple functions with meaningful names.
• Eliminate double negations.
• De Morgan's laws are particularly useful for re-organizing conditional logic.

---

If that is not enough, you can model the business logic with a graph (e.g. decision flowchart) or a Matrix and use the respective standard algorithms.