Software designers talk about  design patterns or the best practices for application designing. The choice is between which mistake is easier to correct: under-doing it or overdoing it. 

We keep on adding ingredients to the curry and food is left with no taste. Let’s explore some anti-patterns and explore the pitfalls of Software designing.

Organisational anti-patterns

• Analysis paralysis -  Devoting disproportionate effort to the analysis phase of the project.
• Cash cow - A profitable legacy product that often leads to complacency about new product.
• Design by committee - The result of having many contributors to a design - but no unifying vision.
• Moral hazard - Insulating a decision-maker from the consequences his or her decision.
• Stovepipe or Silos - A structure that supports mostly up-down flow of data but inhibits cross organisational communication.
• Vendor lock-in - Making a system extensively dependent on an external supplied component.

Design anti-patterns

• Abstraction inversion - Not exposing implemented functionality required by user, so that they reimplement it using higher level functions.
• Ambiguous viewpoint - Presenting a model (OOAD) without specifying its viewpoint.
• Big ball of mud - A system with no recognisable structure.
• Database as IPC - Using DB as message queue for interprocess communication where a more lightweight mechanism would be suitable.
• Gold plating - Continuing to work on a project well past the point at which extra effort is adding value.
• Inner - platform effect - A software so customisable as to become poor replica of software development platform.
• Input kludge - Failing to specify and implement and handling of possibly invalid inputs.
• Interface bloat - making an interface so powerful that it is extremely difficult to implement.
• Magic pushbutton - Coding implementation logic directly within interface code, without using abstraction.
• Race hazard - Failing to see consequences of different orders of events.
• Stovepipe system -  A barely maintainable assemblage of ill-related components.

OOD anti-patterns

• Anemic domain model - Use of domain model without business knowledge.
• Basebean - Inheriting functionality from utility class rather than delegating to it.
• Call super - Requiring subclasses to call a superclass’s overridden method.
• Circle ellipse problem - Subtyping variable-types on the bases of value-subtypes.
• Circular dependency - Introducing unnecessary direct or indirect mutual dependencies between objects.
• Constant interface - using interface to define constants.
• God object - Concentrating too many functionality in a single part of design.
• Object cesspool - Reusing objects whose state does not confirm to the contract of reuse.
• Object orgy - Failing to properly encapsulate objects permitting unrestricted access to their internals.
• Poltergeists - Objects whose sole purpose is to pass information to another object.
• Sequential coupling -  A class that requires its method to be called in a particular order.
• Yo-yo problem - A structure that is hard to understand due to excessive fragmentation.
• Dependency hell - Problem with versions of required product.
• DLL hell - Inadequate management of dynamic linked libraries.

Programming anti-patterns

• Accidental complexity - Introducing unnecessary complexity into a solution.
• Action at distance - Unexpected interaction between widely separated parts of system.
• Blind faith - Lack of checking of correctness of a bug fix or result of a subroutine.
• Boat anchor - Retaining a part of a system that is no longer has any use.
• Busy spin - Consuming cpu while waiting for something to happen, usually by repeated checking rather than message passing.
• Caching failure - Forgetting to reset an error flag when an error has been corrected.
• Cargo cult programming - Using patterns and methods without understanding why.
• Coding by exception - Adding a new code to handle each special case as it is recognised.
• Error hiding - Catching an error message before it can be shown to the user, either showing nothing or showing a meaningless message.
• Hard code - Embedding assumption about environment of a system in its implementation.
• Lava flow - Retaining undesirable code because removing it is too expensive or has unpredictable consequences.
• Loop switch sequence - Encoding a set of sequential steps using a switch within a loop.
• Magic numbers - Including unexplained numbers in algorithm.
• Magic strings - Including literal strings in code, for comparison, as event types etc.
• Soft code - Storing business logic in configuration files rather than source code.
• Spaghetti code - Programs whose structure is barely comprehensible.

Methodological anti-patterns

• Copy-paste programming. Copying (modifying) and pasting existing code rather than implementing generic solution.
• Golden hammering - Assuming that a favourite solution is universally applicable.
• Improbability factor -  Assuming that it is improbably that a known error will occur.
• NHI syndrome - The tendency towards reinventing the wheel, assuming it does not exists here before.
• Premature optimisation -  Coding early on for a perceived efficiency, sacrificing good design, maintainability, and sometimes even real world efficiency.
• Programming by permutation - Trying to approach a solution by successively modifying the code to see if it works.
• Reinventing the wheel - Failing to adopt an existing, adequate solution.
• Reinventing the square wheel - Failing to adopt an  existing solution and instead adopting a custom solution which performs much worse than an existing one.
• Silver bullet - Assuming that a favourite technical solution can solve a larger process or problem.
• Tester driven development - Projects in which new requirements are specified in bug reports.

Phew… don’t stop here explore it on internet there can be more pitfalls that you might be already digging.