Patterns, Technology, UI Design

Anti Patterns

Most of you heard a lot about the software design patterns and most you have used it your day to day software design. The Gang of Four (GoF) patterns are generally considered the foundation for all other patterns. Design patterns are recurring solutions to software design problems in application development.  DoFactory is a good place to start exploring the design patterns, if you are new to patterns.

Ok, enough said about the patterns, here I want talk about the anti patterns. 

What is an anti pattern any way?

It is pattern that tells how to go from a problem to a bad solution to that problem. Anti-Patterns generally represent an effort to define and classify reoccurring non-solutions, i.e., things that lots of projects do that fail to yield a solution, or actually prevent a project from working or being finished. Anti patterns tells you why a  bad solution looks very attractive, and why it is bad and what good pattern are applicable in that case. Identifying bad practices can be as valuable as identifying good practices.

You can think of it as the  old adage, “If your only tool is a hammer, everything looks like a nail”.

Anti Pattern Categories

Architectural Anti Patterns

  • Over-Generalized Interfaces:  Architects often attempt to create systems with infinite flexibility, but only succeed in creating systems that are impossible to maintain. With interfaces,  architects fall in love with the xml interface. All communication between components is done through xml. This created a maintenance nightmare where there are no explicit contracts between interfaces.
  • Over buzzword compliance:  Architects love to find a way to shoehorn the latest buzzword into their architectures, even when there is no fit. Whatever the latest buzzword (xml, REST, WCF), architects will find a way to use it.
  • Product Architecture : Some Architects that are only familiar with a certain product or vendor will design the architecture around the products. The result is often just a marketing sheet, and helps very little to solving the problem at hand.
  • FUD Architecture : The fear of being wrong, or creating an architecture that will change later, results in an architecture that actually solves nothing.

Development Anti Patterns

There is several development anti patterns related to Developers, Scoping,  UI, Tools,  Software Strategy and Development process. You can find more details on these categories in Development Anti Pattern Road Map.  I will point out some of the interesting and most frequent ones here.

  • Control Freek: If a product has a custom language for interacting with the system or its database that doesn’t have equivalent APIs in a common programming language, it ‘will be’ costly to use, customize, and maintain. These specialized languages tend to create high priced experts. This steers business to the vendor’s own consulting services. Most commonly seen in big enterprise software “solutions”.
  • Job Keeper: An undocumented code written for the job security of the current programmer, who can allegedly fix it, usually with more DuctTape.
  • Programmers often miss the distinction between what’s needed and what’s “neat”.
  • ‘Thats Not Really An Issue’: Inexperienced team members running a project ignore concerns that they don’t understand.
  • Voodoo Chicken Coding is when something is not fully understood in a programming problem. This results, typically, in a lot of cut-and-pasting from other code that does something similar, but works; arbitrary reordering of statements; and other tricks.

Management Anti Patterns

  • Band Aid: There is a deep-rooted problem in a company/project that will cause the company/project to fail unless addressed.Unlike the human body, a company/project does NOT heal itself once a band-aid is put over a wound. This Anti Pattern is popular because it is usually quick and painless in the short term, but many long term consequences are ignored. Despite the apparent glossy exterior, a project may now be doomed to fail, because the root problems were not addressed completely or at all!
  • Blame Storming: A discussion – usually amongst adjacent peer-group levels, in which members attempt to assign blame for a particular botch. The  blame is spread thinly enough that not too much sticks to any one individual, and in particular, to no-one in the current group.
  • Scape Goat:  The troubles, even failure, of the project are highly visible. The project is late or over budget or in serious technical difficulty. People are angry and disgruntled and some are even leaving. Management is pressuring to rectify issues with the project. Management find a scapegoat to punish through demotion, re-scoping or removal of responsibilities, or banishment to some area of no value or importance, the ScapeGoat usually does get sacked.
  • Idiot Proof Process: A software team is not delivering.You are under pressure to change something, because the project is clearly broken. You spend weeks in process meetings arguing. In each meeting, you attempt to prevent all possible mistakes that a naive or malignant coder could make. Next, you then argue about whether a given mistake is really always a mistake, or is sometimes a good idea. You begin to doubt the competence of everybody in the meeting, including yourself. Lessons Leaned: You cannot develop an idiot-proof process. A good process depends on good developers to execute it.

See Management Anti Pattern Road Map to read more…

User Interface Anti Patterns

  • Use of rocket science to solve simple problems: Sometimes a designer constructs a solution that is much more complex and confusing than the prior solution. The anti-pattern is often seen when designers have explored new ways of doing things that are then forced upon simple problems. An example is use of drag-and-drop techniques for simple attribute setting. Does a shopping cart need drag-and-drop functionality and are you sure you need fade and fold effects to make your user interface better and more understandable?
  • Designing for the perfect use-case: Some say the user is dumb. But the user never stands a chance guessing your initial intentions. Design your interface defensively and provide feedback to unintended input. Think about how your user interface can and is interpreted by different users and remember to do user testing!
  • Bloated user interface: A bloated user interface tries to incorporate as many operations as can possibly fit into it with the end result of confusing more than helping the user to perform his or her task. A bloated user interface often include features that cannot be used on kinds of data the interface handles.

Organizational Anti Patterns

  • Fear Of Success: Past, often successful projects were threatened by visible problems; Managers implement number of disciplines to eliminate the problems – requirements, testing, architecture, management. Managers have seen those things work in the past. The current important project must be protected from any imaginable problem. No risk is too small to add a full-time worker to mitigate it. Management creates a defensive environment, analogous to large numbers of defenders on a soccer field trying to defend the goal and never attacking.
  • Untested but Finished:  The project is lagging in implementation, and the apparent cause is usually a programming bottleneck – too few or too slow programmers. Managers need to demonstrate progress or enlarge their span of influence; at worse, they want to be able to pretend to make progress. Managers hire outsiders to complete a  portion of the work. On delivery from the outsiders, dictate that the work is complete and only needs to be integrated by the main team. But the work that has supposedly been “finished” by outside forces is unfinished and  unusable.

For more information Organizational Anti Pattern.

Grey Patterns Anti Patterns

Generic Data Model: Generic Data Model is a pattern where all the attributes are separated from the object and saved in different table. It is a very flexible solution but in large databases the performance could be terrible.


This is just a scratch on the surface.  Anti Patterns are good tools to achieve better results in an IT project.  They are as important as the design patterns. Anti Patterns help to identify problems in a project and help to avoid implementing a bad solution to that problem.

Patterns, Technology, UI Design




All input coming from user interaction, such mouse click. are directed to the Controller first. The Controller then kick off some functionality. A single Controller may render many different Views based on the operation being executed.  Also view doesn’t have any knowledge of or reference to the Controller. Controller interact with the Model and pass the model to the View. So there is a knowledge between the View and Model  being passed on to it.


MVP pattern looks very similar to MVC pattern, but has some key distinctions. In MVP, the input is directed to the View not the Presenter. For each View, there is a dedicated Presenter to render that View. The View hold the reference to the Presenter. The Presenter is also reacting to events being triggered from the View, so its aware of the View its associated with it. The Presenter updates the View with the data from the Model and vice versa. But he View is not aware of the Model.


Like MVP pattern, the input is directed to  the View. View hold a reference to the ViewModel. But ViewModel is not aware of the View. So it is possible to have one ViewModel to support many Views. You can have a WPF view, Windows Phone or Silverlight View use the same ViewModel. Also the Model is decoupled from the View.  ViewModel interact with the Model and feed the View with the data.


This is just a scratch on the surface. This help you at a higher level, to understand the main differences between these 3 pattern. There are lot resources out which explain how to program using these patterns.  I will post some more details on these patterns in my future posts.