You're writing software for some customer. You hit a decision point, and so you escalate it to the customer. You explain why you need a decision from them, so they ask you what the options are. You suggest a few things. They may pick one.

Do NOT base your design on their decision. Do not allow it to harden into an assumption, an axiom that you build several other things on. The need to ask the user was a signal that you've discovered an area of flexibility that may not settle down for a few months, or ever.

A trivial example: ''I've put these buttons on the dialog box. Is that okay?'' Customer says, ''Add another button that opens the Web browser on our main corporate site. But apart from that, great!''

Your response to this should be to develop a system for dynamically changing what buttons appear on the dialog box. Make the button labels editable. Provide an extensible palette of actions that can be tied to the buttons. Include an action that executes a script. Another that pops up a little box to type in a parameter, and then hands that to a script as a parameter. I'm serious! You will save weeks of stupid haggling later on. Let the users do that themselves.

''This particular example seems to be against the principles of YouArentGonnaNeedIt and DoTheSimplestThingThatCouldPossiblyWork.  If the user wants just one more button in one dialog, hard-coding it in is probably the simplest solution.  Adding an entire scripting infrastructure to the application to support this one additional feature would be wasteful, assuming that there is no other pressing need for scripting or user-editable toolbars.  If the user asks for customizable GUIs, then give it to them (and charge them for it), but don't do it just because it '''might''' save time later.  And don't forget that if you do this for one dialog, you should RefactorMercilessly and change all the other dialogs to use the same implementation.''

Why is this the case? Because if one user can make a decision about it (regardless of his or her supposed authority within your organisation) then another user can change that decision, for any reason (typically political, but sometimes because they want it to be "perfect.")

The absolute pinnacle of this phenomenon is when deciding names for products. Anyone and their grandmas can get involved in that discussion. So everyone does. The boss, the secretary, the man who fixes the coffee machine will all start contributing. This is why you should not scatter the product name throughout the code. Indeed, you should make it configurable at run time, without a recompile - why wear out the hard disk on the build machine?

More scarily, this principle applies to any DesignDocuments, FunctionalSpecifications, any document that attempts to capture a user's opinion (this week) of what the software should do. Such a document only tells you all the things that you cannot afford to make assumptions about. Anything mentioned in that document is an area that is up for further discussion, because other people involved in the political process will make further contributions, a new guy will be hired who decides to "standardise" everything a different way, etc.

Don't get me wrong, those documents are gold dust, they contain valuable information. But it is ''between'' the sentences.

----
See also AlternateHardAndSoftLayers, ShieldPattern