Developer details pitfalls of using hard-coded values instead of configurable settings

A project has adopted a rule that any value someone might reasonably want to change without altering code should be a configurable setting, not a literal value. One failure mode is creating a setting that no code reads, making the feature silently non-functional. The more common error is keeping the old hard-coded value alongside a new setting, causing changes to have no effect. The article notes that properly removing the original literal after registering a setting is critical for the change to be real.