This post originated from an RSS feed registered with Java Buzz by Michael Cote. Original Post: Anti-Patterns: Design and Requirements Feed Title: Cote's Weblog: Coding, Austin, etc. Feed URL: https://cote.io/feed/ Feed Description: Using Java to get to the ideal state. Latest Java Buzz Posts Latest Java Buzz Posts by Michael Cote Latest Posts From Cote's Weblog: Coding, Austin, etc.

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.