Writing/Product
The word was the feature
The fairest way to split a tip-out was the option nobody chose, because it was labelled with its mechanism instead of its reason.
TeamTipOut can split a shift's tip-out three ways. One of them is meaningfully fairer than the others: each server's contribution goes to the support staff who were actually on the floor at the same time as them, weighted by how long the overlap lasted. Nobody was choosing it.
The reason turned out to be the label. It was called "By overlap". That is a completely accurate description of the mechanism and it is written from inside the code, which is the only place the word overlap means anything.
“A label that describes the mechanism is a label written from inside the code.”
What the user is actually choosing
The person tapping it is not choosing an algorithm. They are choosing between splitting the money evenly and splitting it in a way that reflects who was there. That is a decision about fairness, made at midnight, by somebody who wants to go home.
So the option is called "Fairly", with one line underneath: staff share each server's tip-out in proportion to the hours they actually worked together. Name the outcome, then explain the mechanism in one sentence for whoever wants it. Not one line of the calculation changed.
The rename found a real inconsistency
There was a second benefit I did not go looking for. The same three methods had accumulated two different sets of names across the app, because a label written on the split screen and a label written in the results header had been typed at different times by the same person, who was me.
Renaming forced a single source for the vocabulary, so the words a user reads on the control are now the words on the results screen, in the export and in the explanation. That kind of drift is invisible while you are inside the product and obvious to somebody using it for the first time, which is the entire problem with being the person who built the thing.
