Hardcoding feature flags, particularly for kill switches or short-lived A/B tests, is often a pragmatic and acceptable approach. While dynamic feature flag management systems offer flexibility, they introduce complexity and potential points of failure. For simple scenarios, the overhead of a dedicated system can outweigh the benefits. Directly embedding feature flags in the code allows for quicker implementation, easier understanding, and improved performance, especially when the flag's lifespan is short or its purpose highly specific. This simplicity can make code cleaner and easier to maintain in the long run, as opposed to relying on external dependencies that may eventually become obsolete.
The blog post, titled "It's OK to hardcode feature flags," argues against the prevailing wisdom that feature flags should always be managed through a dedicated service or configuration file. The author, Mendhak, posits that for certain types of feature flags, specifically those tied to permanent features intended to eventually become a standard part of the application, hardcoding them directly into the codebase can be a more efficient and less complex approach.
Mendhak begins by acknowledging the common use cases for feature flag management systems: A/B testing, canary releases, and kill switches. These scenarios require dynamic control over features, enabling rapid activation, deactivation, or modification without requiring a new deployment. However, the author contends that not all feature flags fit this mold. Some features are developed with the explicit intention of being permanently enabled once they are deemed stable and ready. For these "permanent" feature flags, using a complex management system introduces unnecessary overhead and complexity.
The argument centers on the idea that maintaining a feature flag within a separate system creates ongoing maintenance burden and increases the cognitive load for developers. Developers must remember to eventually remove the flag and its associated logic from both the codebase and the feature flag system, a task that can easily be overlooked. Hardcoding the flag, on the other hand, allows for a simpler, more self-documenting approach. When the feature is ready to be permanently enabled, the flag and its conditional logic can be directly removed from the code, leaving no lingering remnants in external systems. This simplification reduces the risk of errors, improves code readability, and streamlines the development process.
Mendhak suggests a specific approach for hardcoding these permanent feature flags: Use a simple boolean variable within the codebase, initialized to false. When the feature is ready, change the variable to true and deploy the updated code. Once the feature has been live and confirmed stable for a sufficient period, the flag and its associated conditional code can be removed entirely. This process avoids the complexities of external dependencies and keeps the feature's lifecycle entirely within the codebase itself.
The author emphasizes that this approach is not suitable for all feature flags. Dynamic feature flags, like those used for A/B testing, still benefit from dedicated management systems. However, for features destined to become standard components of the application, hardcoding provides a cleaner, more efficient, and less error-prone alternative. This targeted use of hardcoded flags reduces the overall complexity of the system, simplifying maintenance and improving code clarity in the long run.
Summary of Comments ( 54 )
https://news.ycombinator.com/item?id=42899778
Hacker News users generally agree with the author's premise that hardcoding feature flags for small, non-A/B tested features is acceptable. Several commenters emphasize the importance of cleaning up technical debt by removing these flags once the feature is fully launched. Some suggest using tools or techniques to automate this process or integrate it into the development workflow. A few caution against overuse for complex or long-term features where a more robust feature flag management system would be beneficial. Others discuss specific implementation details, like using enums or constants, and the importance of clear naming conventions for clarity and maintainability. A recurring sentiment is that the complexity of feature flag management should be proportional to the complexity and longevity of the feature itself.
The Hacker News post "It's OK to hardcode feature flags" generated a moderate amount of discussion, with several commenters offering their perspectives on the practice.
One of the most compelling threads explored the nuances of "hardcoding" and its implications for different contexts. Some argued that true hardcoding, where a feature flag is permanently embedded in the code with no easy way to change it without recompilation and redeployment, is indeed problematic and should be avoided. They emphasized that the value of feature flags comes from their flexibility and ability to toggle functionality without new releases. However, others pointed out that the article's usage of "hardcoding" might refer to situations where the flag's value is set during the build process or initialized at runtime, rather than being truly immutable. This type of "hardcoding" could be acceptable, especially for features that are intended to be permanently enabled or disabled for specific builds or environments (e.g., demo versions, A/B testing). This distinction between permanently embedding a value and setting it during build/initialization was a key point of discussion.
Another commenter highlighted the importance of considering the feature's lifespan. For short-lived features, hardcoding (especially in the sense of setting the value at build time) might be acceptable, as the code will likely be removed or refactored soon anyway. However, for long-lived features, a more robust and dynamic approach to feature flagging is generally preferred.
A recurring theme was the balance between pragmatism and best practices. Several commenters acknowledged that while ideally feature flags should be managed through a dedicated system, practical constraints, such as limited resources or tight deadlines, can sometimes justify simpler, hardcoded approaches. One comment even suggested that for small projects or teams, the overhead of a feature flag management system might outweigh its benefits.
Some users shared their personal experiences and preferences, some advocating for build-time configuration as a sensible middle ground, allowing for customized builds without sacrificing the ability to permanently enable or disable features for different deployments. Others cautioned against overusing feature flags, suggesting that they should be primarily employed for major features or risky changes, not for every minor tweak.
While there wasn't overwhelming consensus on the absolute right or wrong way to handle feature flags, the discussion provided a valuable exploration of the trade-offs involved, highlighting the importance of context, feature lifespan, and resource constraints in making informed decisions.