Oggi mi sto facendo un sacco di risate a leggere in giro sugli anti-pattern
Un anti-pattern è un pattern di programmazione che viene ritenuto in genere pericoloso o totalmente sbagliato per alcuni motivi.
Faccio degli esempi:

Fede cieca (blind faith)
Mai capitato di essere troppo sicuri del fatto che ciò che si è scritto funzionerà sicuramente senza testarlo prima di mandarlo in produzione????? ;)

Vicolo cieco (dead end)
Avviene quando ci si fida troppo di dll o framework di terze parti. Il rischio maggiore è il costo di manutenzione necessario nel tempo... ancora maggiore nel caso in cui il produttore la dismetta, costringendoci a cracking del codice e aggiornamenti in proprio. Questo non vuol dire evitare di comprare componenti esterni, ma bisogna analizzare bene il comportamento del produttore oltre a quello del componente, ancora meglio se si riesce a contattare il produttore e fare un serio contratto di assistenza. Aggiungo anche che benchè si ritenga che il software open sia esente da questo problema, in realtà le cose variano, ma non cambiano: bisognerà sempre aggiornarsi il componente in casa, e poi cercare di convincerne il gestore a considerarlo nelle sue future release... e se questo non accade? si fa un fork?!?!?!?!

Spaghetti code
Questo è un classico..... anche se i goto non si usano più molto (per fortuna) il concetto non cambia: avviene quando il flusso di controllo del codice (il flusso di programmazione) ha poca linearità e troppi salti.
Un esempio nella programmazione strutturata erano proprio i GOTO usati al posto dei LOOP/FOR.
Ad oggi è uno spaghetticode anche quando non si rispettano i layer dell'applicazione (vedi azione a distanza)

Azione a distanza (action at a distance)
Il concetto è appunto che non dovrebbero esserci sconfinamenti tra i layer che compongono la nostra applicazione. Il concetto base è che i componenti (o anche i layer) devono comunicare solo con quelli che gli sono vicini, mandare un DataRow dal DAL direttamente alla ComboBox non è una cosa tanto corretta..... e qui interviene anche il concetto (pattern) di separation of concerns... che poi per comodità alcuni lo fanno è un altro discorso, ma nel tempo ed alla prima modifica di qualche classe o di qualche tabella, la manutenibilità della nostra applicazione, va a prendere il sole!

Attesa a vuoto (busy spin)
Questo è il classico loop, quando ad esempio di scrive:
for (true)
{
 try { 
  var bytes = System.IO.File.ReadAllBytes("pippo.dat");
  break;
  }
  catch (Exception ex)
{}
}
e magari il file nn c'è.........

Inversione dell'astrazione (abstraction inversion)
Quando si usa un implementazione come base per un astrazione:
se ad esempio si usa una SqlTransaction (un implementazione fortemente orientata al DB con alti costi) per fare del synclock (un astrazione), magari ignorando che esiste già. Certo questo non è un concetto assoluto, e molti lo contestano, anche se in questo esempio, quasi tutti concorderebbero!

Reinventare la ruota (reinventing the wheel)
Mai capitato di scrivere la stessa cosa in 2 o 3 persone diverse?!?!?!?!?! Cmq di solito qui l'errore è la mancanza di comunicazione tra persone o un manager incompetente.

Programmazione a regali (cargo cult programming)
Mai visto nessuno mettere nella propria applicazione pezzi di codice completamente inutili, o sbagliati, o presi chissà dove, solo perchè gli sono capitati d'avanti?!?!?!!? PS: il nome deriva da un culto nato da alcuni che credono al fatto che i regali dell'ONU che lanciano dagli aerei, siano doni del cielo ;)

Carica e spara (accumulate & fire)
Altro errore frequente è usare molte variabili globali, da popolare in massa, prima di poter lanciare una routine. Questo oltre ad essere per niente thread-safe, è anche un problema nella manutenibilità e può fare da base all'azione a distanza nel momento in cui si aggiornano le classi delle variabili globali.

Sper di scrivere ancora altro sull'argomento... ciao