Anti Patterns?

Reply 1

Anti-patterns tend to be more bad practices and emergent behaviors then patterns.  There usually isn't a defined way to do something badly, people take the time to figure it out themselves :)

An example I recently saw has to do with multiple programmers and ambiguous design.  Data was being pulled in from a legacy system and the developer had created a "Client Clean" table and a "Client" table.  The data would come in to the "Client Clean" table and would be cleaned and moved over to the "Client" table. The website then would read from the "Client" table. At this point you may notice that there are 2 client tables where 2 different programs access them which is not exactly an Anti-pattern but it does mean anyone working on the systems will need to know what each table is and what accesses it.  Later that year a new programmer came in and created some more pages for the clients, at that point a new behavior emerged; people started getting random client names.

Some other of my favorites are:

1) calling a webservice from a stored proc

2) YAML files for business logic

3)  managing program flow with exception handles

4) using super methods that have been overridden

5) optimizing before the core functionality is complete

6) automagic frameworks

but basically if you look up antipatterns like here you will notice they are things you shouldn't do , not patterns really.