TLDR: It’s often easier to tweak the environment than it is to change behavior directly, especially in the face of limited resources.
One of my favorite Chief Technology Officers once told me “First you program the code, then you program the people, then the organization.” There’s a lot of truth in that statement, but it’s not quite that simple.
We all have inputs and outputs, but the logic that drives our behavior is locked within the black box of our individual psychology. The same input can have very different outputs on any given day. People are complicated.
Changing behavior is hard. Changing an organization’s behavior is really hard. An approach that works with one person might not work with another, and it’s easy for individuals to fall back into bad habits. Faced with limited resources and tight deadlines, it’s often easier to tweak the environment than it is to change behavior directly. …
TLDR: Feature flags are dangerous, and there are better ways of accomplishing what you’re trying to do.
Feature flags (AKA feature toggles) are frequently used in unhealthy ways far beyond the scope of their original design. They are highly flexible, but leveraging that flexibility comes with drastically increased complexity and risk:
- Lack of clarity on what code is actually running in production
- Code is hard to change due to added complexity
- “Land mines” of stale or dead code that is poorly understood
- Poor signaling within the code base of what has actual value
- Multiple code paths, making testing harder, and less likely we’ll do it…
About
