On this page4 sections
The configuration file is shorter. The incident takes longer to untangle. In this hypothetical cleanup, a team has moved visible feature flags into customer-specific overrides held by another service. During a failure, the responder now needs another lookup, and perhaps another team, to discover which behavior the application is using.
“Keep it simple,” commonly called the KISS principle, is useful when we ask simple for whom. The person editing the file, the program reading it and the person recovering the service may encounter different costs. For reliability work, count what the next responder must understand and recover, including the parts moved out of sight.
The choices survive the shorter file
An independent on/off flag doubles the possible combinations. One permits two; two permit four; ten permit up to 1,024. Real rules can make some combinations unreachable, so this is not a demand for 1,024 separate tests. It is a reason to identify the behavior the service actually supports rather than judge complexity by file length.
The customer override in our example still changes the application's behavior. Moving it leaves that support obligation intact. A view of the effective configuration can help: show the values the running instance actually uses after combining defaults, customer overrides and deployment settings, and show where each came from.
Now an unexpected behavior has a path back to the choice that produced it. Removing a genuinely unused override goes further by eliminating a behavior altogether. Both can simplify the responder's job; they do different work. One makes an existing state easier to understand, and the other removes a state the team had to support.
Read diagram description
Two independent binary flags produce four combinations; ten permit up to 1,024. Constraints may make some unreachable. Identify which supported combinations are tested and visible at runtime. Rows show flag B off and on; columns show flag A off and on. The four cells are all combinations of the two flags.
Find out who still needs the exception
A temporary override can outlive the conversation that created it. Before retiring it, find the remaining users, who can move them and what would make removal valid. An expiry date prompts a review. It does not prove the users have moved.
That distinction protects useful complexity as well. Two storage paths may duplicate effort, or one may deliberately preserve a recovery route. A necessary customer or migration behavior can be worth its cost. Keep it visible and test its supported combinations rather than remove it for a cleaner drawing.
Watch the transition too. An automation might update the override and stop before updating the dependent job. Showing those two results lets a responder continue from the unfinished part. A single “failed” label hides the successful change and invites a repeat.
Even after nobody has the flag enabled, old messages, stored records or scheduled jobs may depend on the former behavior. Decide how those objects will be handled before taking away their recovery path. A later replay can otherwise revive a state everyone thought was retired.
Undoing the setting does not undo the data
Follow one proposed change all the way through. The new value changes behavior; the behavior writes data; someone restores the old value. The application now has old configuration and new data, a combination it may never have occupied before. The review needs to show whether it works and how an operator can recognize and recover it.
A canary rollout can exercise supported behavior for a limited population. Keep the sample's coverage visible instead of treating one successful run as exhaustive. Consequential unverified combinations belong in the risk registry, where their uncertainty and cost can inform the next decision.
Earn the smaller configuration
Retire the override as a migration with users. Move a limited population, examine normal operation and recovery, and keep the old path while it remains a valid rollback option. Remove it when the agreed retirement condition is met. The small file then records a real reduction in the work the service demands.
Until then, a longer view that explains the effective configuration may be the simpler thing to operate. The next responder can see what the application is doing without a treasure hunt across services. That is a useful meaning of “keep it simple”: less to figure out, and less to put back together.
Source context
This article does not include external reference links. Read it as the author’s perspective and evaluate the guidance against your environment.
Report an error or outdated detail