Here’re two patterns of doing design that I’ve noticed recently:

Design by Exhaustion

Two or more people debate furiously about the best
way to design something. One of them gets tired of discussing the design
and simply gives up. The one who can hold out the longest wins!

Requirements by Siege

At higher levels in an organization, when
deciding on requirements or whole systems to implement, “Design by
Exhaustion” takes on a slightly different form: which ever sub-group
in the organization can hold out longest, waiting for the other to
give up (either go away or starve) gets their way. In the mean time,
the customer takes their money to your competition. Have fun storming
the castle!

Requirements/Design by Anecdote

Someone has heard a story about
a customer who wanted some feature in their product. They don’t really
remember who it was (who takes notes on these kinds of things?), but
they remember it was really important. After some period of time, the
story is transformed into an either:

• An Anecdote – an extremely narrow use cases, aka, “Edge Cases”,
  that’s been widened to all customers. E.g., “a customer wanted to
  get emails for all purple whiz-boggles created that are only
  85% taste-effective as measured by the International Tasting
  Standards Body. This is very important to our customers! Pull
  all the stops!”, or,

• A “myth”/”legend” – a requirement that has been so generalized
  as to be meaningless, and yet demanded by “all our customers.” For
  example, “our customers demand that the product scale,” or, “our
  customers demand that the product be usable!”

Dealing

As is the case with all anti-patterns, these are actually patterns
used day-to-day developing software in the large. Avoiding them
completely is impossible. Containing their damage is the more realistic
route.