The argument for apologising
- The guidance quoted by the accepted answer is to write the message in the tone you would use if you were telling the person face to face.
- The stronger version, from a second answer, is that it is not merely acceptable but required: if someone has hit a wall, it is because the system failed to make its own rules legible, and that is the system's responsibility rather than theirs.
- The apology, on this reading, is not decoration. It is an accurate statement of where the fault lies.
The dissent
One answer rejected the premise outright, comparing an apologising program to a recorded telephone message insisting your call is important. Their position was that an apology from software humanises nothing, and that the energy belongs in making the message clear enough to act on without overwhelming the reader. Notably this answer did not argue for a colder tone — it argued that tone is the smaller variable and gets more attention than it earns.
The answer that reframes it
The most useful contribution stepped back from wording entirely and asked why the unavailable feature was visible at all. If someone cannot use it, hide it. If it exists to sell an upgrade, say so plainly and explain what the upgrade gives them and who to ask. On that view the original message is a symptom: a well-designed interface would rarely need to apologise for a permission problem, because it would not have offered the option.
What to take from it
- Apologise where the system genuinely is at fault — an outage, a failure, a rule that was never explained.
- Do not apologise for enforcing a rule the person could reasonably have been told about earlier. Fix the earlier moment instead.
- Whatever the tone, the message must say what happened and what to do next. Every answer agreed on that, including the one that disagreed about everything else.