UI Copy Is a Spec
When code breaks a promise the screen made, lowering the promise is always cheaper. Two cases where I kept the words and fixed the behaviour instead.
When you find that a sentence on the screen and what the code does have drifted apart, there are two ways to close the gap. Change the sentence to match the behaviour, or change the behaviour to match the sentence. The first is almost always cheaper. One line of copy changes, and no test breaks.
I met that fork twice recently, in two different products. Both times the cheap path showed up first, and both times I did not take it. A sentence on a screen is not a description. It is a contract with the person reading it, which makes a mismatch a defect rather than a wording problem.
The switch was already a promise
DUGOUT 9 is a companion web app for following games in the KBO, Korea's professional baseball league. It is the public demo of an independent fan project, not an official service. Its settings had a public profile switch, off by default. The ranking, meanwhile, showed the nickname and team of every fan with a score. The switch's value was saved. Nothing ever read it.
There were two easy ways to make the two sides agree: remove the switch, or flip its default to on. Either would have left the code alone and made the screen true. I went the other way. The default stayed off, and the ranking now hides the identity of anyone who has not turned it on.
The team rankings look noticeably emptier as a result. But lowering a promise the screen has already made is, from the user's side, a setting quietly betrayed. For the same reason, reset records now deletes what is stored on the server, and the privacy notice was rewritten to list what is actually kept.
The default when nobody touches anything
HappyBirthTown is a birthday gift in the form of a small pixel town that friends build together. It once had a group photo taken at 10 pm. When a guest claimed an empty spot on the plaza, the screen told them, "You'll be in the 10 pm photo." The shutter time was left to the host's schedule.
The feature was finished and the checks passed. Going back over it clause by clause afterwards, I found the hole: the schedule was empty by default. If the host did nothing, a guest could claim a spot and decorate it, and the shutter would never fall. The screen had made a promise whose keeping depended on someone else acting. That is not a promise. It is an assumption.
So the shutter now schedules itself the moment the first guest claims a spot. The host still owns the party. If they had set a time, nothing changes; if they set one later, theirs wins. But the default for when the owner says nothing now sits on the side that keeps the promise. "The host can open it" was the tidier permission model, and the guests would have paid for the tidiness. (The photo has since changed into one with no gathering hour at all; that story is in One Fixed Hour Makes the Whole Product Synchronous.)
Giving the person with authority the decision, and letting nothing happen when that person stays silent, are two separate decisions. The second one is usually never made. It just ends up that way.
Don't let the cheap fix be the default
Both times what changed was the behaviour, not the words, and the test for which side to change was the same. Not cost, but what the person had believed and acted on. Whoever switched off their profile believed their name would not appear. The guest who claimed a spot believed they would be in the photo. Once someone has acted on that belief, you cannot rewrite the sentence later and tell them it was never true.
Rewriting the copy to match is always possible and always cheaper, which is exactly what makes it dangerous. Make it the default and a product learns to lie one line at a time, without anyone ever deciding that it should. Every sentence put on a screen brings a duty to keep it. I want to remember that when the sentence is written, not when the mismatch is found.