Anti-Pattern

Ein Anti-Pattern (aus dem Englischen, übersetzt etwa Antimuster) ist in der Softwareentwicklung ein häufig anzutreffender schlechter Lösungsansatz für ein bestimmtes Problem. Es bildet damit das Gegenstück zu den Mustern (Entwurfsmuster, Analysemuster, Architekturmuster, …), welche allgemein übliche und bewährte Problemlösungsansätze beschreiben.

Muster wurden vor allem durch die Entwurfsmuster aus dem Buch Design Patterns der Viererbande bekannt. Diese Entwurfsmuster umfassen jeweils eine Beschreibung der Problemsituation und einen Vorschlag, wie das Problem gelöst werden kann. Nachdem bei der Softwareentwicklung immer mehr von positiven Erfahrungen aus erfolgreich abgeschlossenen Aufgabenstellungen profitiert wurde, konzentrierte man sich auch darauf, die Negativbeispiele, also wiederkehrende Fehler bei der Softwareentwicklung, zu identifizieren, zu dokumentieren und Maßnahmen aufzuzeigen, wie sie behoben werden können.

Mithilfe solcher Dokumentationen können bereits manifestierte Anti-Pattern gefunden und behoben werden. Außerdem hilft das Kennen dieser Anti-Pattern, solche Fehler von vornherein zu vermeiden.

In der Regel entstehen Anti-Pattern wider besseres Wissen, durch mangelnde Erfahrung oder fehlende Qualifikation. Zu beobachten ist allerdings auch die bewusste Verfolgung in bestimmten Szenarien, um einen bestimmten Zweck zu erreichen. Die Auswirkungen des Auftretens von Anti-Pattern reichen von marginal bis unternehmenskritisch.

Kategorisierung

Mittlerweile werden Anwendungsbereiche der Anti-Pattern immer feiner unterschieden. So unterscheidet man Anti-Pattern bei der reinen Programmierung (hier spricht man auch von Code smells, die bei Existenz und Identifikation durch Refactorings entfernt werden können), bei Architektur und Design, beim Projektmanagement, bei Unternehmensprozessen, bei der Unternehmensorganisation und dem Management. Darüber hinaus können in der Praxis immer mehr sogenannte Meta-Patterns identifiziert werden. Diese vereinen einzelne Muster zu einem neuen, abstrakteren Mustern oder führen eine weitere Dimension oder abstraktere Kategorisierung ein.

Projektmanagement-Anti-Pattern

Blendwerk

Blendwerk (englisch Smoke and mirrors) bezeichnet nicht fertige Funktionen, welche als fertig vorgetäuscht werden.

Aufgeblähte Software

Aufgeblähte Software bezeichnet Software, bei der jede neue Version mehr Ressourcen benötigt.

Feature creep

Feature creep (Erschleichung von Funktionalität) bezeichnet es, wenn der Umfang der zu entwickelnden Funktionalität in einem Projektplan festgehalten wird, diese aber dauernd erweitert wird.

Der Kunde versucht, nach der Erstellung des Projektplanes weitere Funktionalität in die Version mit unterzubringen. Dies führt zu Problemen, wenn die in Arbeit befindliche Version nicht das notwendige Design aufweist, Termine nicht eingehalten werden können oder die realen Kosten über die planmäßigen Kosten wachsen.

Bei schwergewichtigen Prozessen ist dies sehr gefährlich. Bei leichtgewichtigen Prozessen wie XP müssen bei allen Beteiligten die Konsequenzen klar sein. Ein systematisches Anforderungsmanagement und Änderungsmanagement sind obligatorisch. Gewisse Änderungen am Projektplan während der Entwicklung sind in größeren Projekten schwer vermeidbar, denn die Spezifikationen bis ins letzte Detail auszuarbeiten ist meist noch aufwendiger als etwas Reserve einzuplanen. Auch können Anforderungen erst während der Entwicklung entdeckt werden.

Extreme, böswillige und grob fahrlässige Anwendung dieses Musters kann dadurch motiviert sein, dass der Auftragsteller, der immer neue Funktionalität fordert, das Produkt boykottieren möchte und dessen Abschluss zu verhindern sucht oder er hat bei der Planung bewusst eigentlich benötigte Funktionalität unterschlagen, um eine günstigere Offerte zu erhalten.

Durch ein Wortspiel, dessen Inhalt die Wandlung von Creeping Feature zu Feeping Creature umfasst, wird der Umstand ausgedrückt, dass eine Verselbstständigung von Anforderungen und Implementierungen unnötiger oder nicht in das Gesamtkonzept passender Leistungsmerkmale stattgefunden hat.

Scope creep

Die Scope creep (Erschleichung weiterer Anwendungsbereiche) ist ähnlich wie der Feature creep, jedoch nicht auf Funktionalität bezogen, sondern auf den Anwendungsbereich. Auch hier zeichnet sich der Auftraggeber dadurch aus, dass er geschickt und versteckt den Umfang der Software nachträglich erweitern möchte, ohne dass er dies explizit zugibt. Beispiel: nicht diskutierte Anwendungsbereiche sind plötzlich sehr wichtig bzw. das Fehlen eines Bereiches wird sogar als Fehler dargestellt, der dringendst behoben werden muss.

Brooks’sches Gesetz

Das Brooks’sche Gesetz besagt, dass ein Projekt, welches sich hinter dem Zeitplan befindet, länger benötigt, wenn neue Mitarbeiter eingestellt werden, weil die neuen Mitarbeiter Zeit benötigen, um sich einzuarbeiten.

“Adding manpower to a late software project makes it later.”

„Mitarbeiter zu einem verspäteten Softwareprojekt hinzuzufügen, verzögert das Projekt nur noch weiter.“

– Frederick Brooks

Death Sprint

Bei einem Death Sprint (Überhitzter Projektplan) wird Software iterativ bereitgestellt. Die Bereitstellung erfolgt hierbei in einer viel zu kurzen Zeitspanne. Nach außen sieht das Projekt zunächst sehr erfolgreich aus: immer wieder neue Versionen mit neuen Eigenschaften werden abgeschlossen. Allerdings leidet die Qualität des Produktes sowohl nach außen sichtbar, wie auch technisch, was allerdings nur der Entwickler erkennt. Die Qualität nimmt ab mit jeder „erfolgreichen“ neuen Iteration. Gegenteil von Death March.

Death March

Ein Death March (Todesmarsch) ist das Gegenteil von einem Überhitzten Projektplan. Ein Todesmarschprojekt zieht sich ewig hin.

In einem optimalen Fall werden zwar Vorabversionen bereitgestellt, welche aber von schlechter Qualität sind. Der Misserfolg ist objektiv sichtbar. Es können keine Meilensteine gehalten werden bzw. es existieren gar keine. Schlimmstenfalls kann eine Konsequenz daraus sein, dass das Projekt kein Projekt mehr ist, sondern nur eine zeitlich nicht abgeschlossene Aneinanderreihung von Aktivitäten. Es fehlen konkrete Zusagen für Termine und Lieferung von Eigenschaften.

Ein Todesmarschprojekt kann auch bewusst in Kauf genommen werden, um von Defiziten in der Organisation abzulenken und Entwicklungen zu verschleppen, d. h. so lange an etwas zu entwickeln, bis eine nicht genau spezifizierte Eigenschaft in irgendeiner Form subjektiv funktioniert. Wenn sowohl Anforderungsmanagement als auch Änderungsmanagement nicht vorhanden sind und das Projekt kein Projekt mehr ist, so schlenkert das Entwicklungsprodukt orientierungslos umher und seine Qualität nimmt stetig ab.

Ein Todesmarschprojekt kann auch mit einem Überhitzten Projektplan (s.o.) kombiniert werden, um nach außen von Planungslosigkeit und Defiziten bei Organisation und Technik abzulenken. Es wird dann Funktionalität als neu dargestellt, die bereits lange existiert, oder es existiert keine Kontrollinstanz, die Notwendigkeit, Relevanz, Form, Korrektheit und Wichtigkeit von bereitgestellter Funktionalität bewertet.

Beispiel

Neuanforderungen von gestern sind (nicht: beinhalten!) die Bugs von morgen.

Ein Todesmarschprojekt kommt häufig vor, wenn es keine Stakeholder gibt, die Interesse an dem Produkt haben, oder wenn der in das Produkt einfließende Aufwand oder sogar das ganze Produkt letztendlich keine Bedeutung/Wichtigkeit hat. In diesem Fall beschäftigt sich die Unternehmung oder die Entwicklungsabteilung nicht selten (mit sich) selbst.

Architektur- bzw. Entwurfs-Anti-Pattern

Big Ball of Mud

Software, die keine erkennbare Softwarearchitektur besitzt, wird als Big Ball of Mud (Großer Matschklumpen) bezeichnet.

Gasfabrik

Als Gasfabrik (englisch Gas factory) werden abwertend unnötig komplexe Systementwürfe für relativ simple Probleme bezeichnet.

Gottobjekt

Die Begriffe Gottobjekt (englisch god object), Gottklasse (God class) und Blob bezeichnen ein Objekt, das zuviel weiß bzw. macht. Die Aufteilung nach Verantwortlichkeiten, Kapselung und die Einhaltung von Entwurfsmustern helfen, diesem Muster zu begegnen.

Innere-Plattform-Effekt

Der Innere-Plattform-Effekt (englisch Inner platform effect) tritt auf, wenn ein System derartig weitreichende Konfigurationsmöglichkeiten besitzt, dass es letztlich zu einer schwachen Kopie der Plattform wird, mittels derer es gebaut wurde. Ein Beispiel sind Datenmodelle, die auf konkrete (anwendungsbezogene) Datenbanktabellen verzichten und stattdessen mittels allgemeiner Tabellen eine eigene Verwaltungsschicht für die Datenstruktur implementieren mit dem eigentlichen Ziel, die Flexibilität zu erhöhen. Derartige Systeme sind allerdings typischerweise schwer zu beherrschen und leiden häufig unter zusätzlichen Performanceproblemen.

Spaghetticode

Spaghetticode ist eine sehr kompakte Systemstruktur, die von Sprungbefehlen geprägt ist, deren Kontrollfluss einem Topf Spaghetti ähnelt.

Sumo-Hochzeit

Als Sumo-Hochzeit (englisch Sumo Marriage) bezeichnet man es, wenn ein Fat Client unnatürlich stark abhängig von der Datenbank ist.

In der Datenbank ist hierbei sehr viel Logik in Form der datenbankeigenen Programmiersprache positioniert. Beispielsweise in Oracle mit der Programmiersprache PL/SQL. Die ganze Architektur ist dadurch sehr unflexibel.

Soll die Anwendung zu einer Internet-Anwendung migriert oder die Datenbank gewechselt werden, so müssen auf beiden Schichten (Client und Datenhaltung) viele Bereiche neu entwickelt werden. Die Systeme sind nicht entkoppelt.

Programmierungs-Anti-Pattern

Doppelt überprüfte Sperrung

Eine doppelt überprüfte Sperrung (englisch double-checked locking) tritt auf, wenn eine doppelte Überprüfung durchgeführt wird, bevor eine Sperrung erfolgt. Dieses Muster wird häufig von unerfahrenen Programmierern genutzt, die von der Problematik des Lockings wissen, aber die falschen Schlüsse ziehen.

Zwiebel

Als Zwiebel (engl. Onion) bezeichnet man Programmcode, bei dem neue Funktionalität um (oder über) die alte gelegt wird.

Häufig entstehen Zwiebeln, wenn ein Entwickler ein Programm erweitern soll, das er nicht geschrieben hat. Der Entwickler möchte oder kann die bereits existente Lösung nicht komplett verstehen und setzt seine neue Lösung einfach drüber. Dies führt mit einer Vielzahl von Versionen und unterschiedlichen Entwicklern über die Jahre zu einem Zwiebel-System.

Copy and Paste

Programmierung mittels Kopieren und Einfügen (englisch Copy And Paste Programming) bezeichnet es, wenn der Programmierer den Code nicht neu entwickelt, sondern sich bereits existenter Quelltexte bedient, aus denen er Passagen herauskopiert.

Die Gefahr ist hierbei sehr groß, dass er Fehler mitkopiert oder die Kopie für den neuen Bereich nicht optimal einsatzbereit ist. Der Entwickler reflektiert weniger über sein Programm, als wenn er jede Zeile selbst entwickeln würde. Hierbei handelt es sich um ein fehleranfälliges Vorgehen, wenn der Entwickler nicht weiß, was er eigentlich macht. Die Wartbarkeit des Codes wird reduziert, wenn der (fast) gleiche Programmcode an vielen Stellen vorkommt. Anstatt zu kopieren, sollte eine gemeinsame Funktion ins Auge gefasst werden.

Lavafluss

Ein Lavafluss (englisch Lava flow) beschreibt den Umstand, dass in einer Anwendung immer mehr „toter Quelltext“ herumliegt. Dieser wird nicht mehr genutzt. Statt ihn zu löschen, werden im Programm immer mehr Verzweigungen eingebaut, die um den besagten Quelltext herumlaufen oder auf ihm aufbauen.

Magische Werte

Bei Magischen Werten (englisch Magic Values) handelt es sich um Daten (Literale) mit besonderer Bedeutung. Sie sind hartkodiert (englisch hardcoded) und nur mit besonderem Wissen über die konkrete Verwendung zu verstehen. Werte sollten zentral als Variable definiert werden, optimalerweise als typsicheres Objekt.

package test; 

/**
 * "Magic Values" und "Switch-Statement" Anti-Pattern
 * 
 * @author Wikipedia
 */
public class Bar {
  public static void main(String[] args) {
    Bar bar = new Bar();
    // hart codierter Wert 
    bar.go(7);
  }
  public void go(int param){
    // konditionale Behandlung eines Wertes
    switch(param) {
      case 1:  System.out.println("a"); break;
      case 3:  System.out.println("b"); break;
      case 7:  System.out.println("c"); break;
      case 12:  System.out.println("d"); break;
      default: System.out.println("x"); break;
    }
  }
}

Reservierte Wörter

Die Verwendung von reservierten Wörtern, etwa in SQL-Anweisungen, kann zu schwer zu findenden Fehlern führen. Ein Austausch der Datenbank eines Herstellers gegen ein anderes Produkt kann dazu führen, dass weitere Namen als reserviert betrachtet werden müssen.

Unbeabsichtigte Komplexität

Als Unbeabsichtigte Komplexität (englisch Accidental complexity) wird eine programmierte Lösung bezeichnet, welche komplexer ist, als es für das zu lösende Problem erforderlich und angemessen wäre. Dieses Anti-Pattern ist verwandt mit der Gasfabrik.

Organisations-, Management- bzw. Prozess-Anti-Pattern

Wunderwaffe

Eine Wunderwaffe (englisch Golden hammer) ist ein bevorzugter Lösungsweg, der als universell anwendbar angesehen wird.

Das Rad neu erfinden

Mit das Rad neu erfinden (englisch Reinventing the wheel bzw. Not-invented-here-Syndrom) wird die stetige Neuerstellung von Software – ohne bestehende Lösungen oder Frameworks zu nutzen – bezeichnet. Da keine Wiederverwendung erfolgt, erhöht sich der Entwicklungsaufwand, was zu unreifer und teurer Software führt.

Das quadratische Rad neu erfinden

Mit das quadratische Rad neu erfinden (englisch Reinventing the square wheel) bezeichnet man die Bereitstellung einer schlechten Lösung, wenn eine gute Lösung bereits existiert.

Beispiel aus der Java-Welt

Eigene Entwicklung einer Persistenz-Schicht, obwohl es hier Standards gibt wie JPA.

Body ballooning

Beim Body ballooning handelt der Vorgesetzte ausschließlich aus der Bestrebung heraus, seine Machtposition auszubauen, welche sich entweder aus der Unternehmensstruktur oder auch rein subjektiv aus der Anzahl der Mitarbeiter unter sich definiert. Dies kann dazu führen, dass der Vorgesetzte bewusst arbeitsintensivere Lösungen und Arbeitstechniken den effizienten vorzieht.

Empire building

Durch sachlich nicht nachvollziehbare, nicht konstruktive Maßnahmen versucht ein einzelner, seine Macht auszubauen bzw. zu erhalten. Dies kann Body ballooning sein, aber auch das ständige Beschuldigen anderer, gerade derer, die nicht mehr für die Unternehmung arbeiten, die Ausführung von pathologischer Politik, Diskreditierung, Mobbing und sonstige Facetten, die nur darauf abzielen, die eigene Position zu stärken bzw. den eigenen Status zu halten. Dieses Muster zeichnet sich auch dadurch aus, dass die Person es vermeidet, Verantwortung zu übernehmen, und schriftliche Beweise für Vorkommnisse und Entscheidungen zu verhindern weiß. Somit muss er sich an diesen nicht messen lassen, was es auch einfacher macht, bei Misslingen eines Projektes die Verantwortung an einen anderen einfach weiter zu delegieren. Hier wird auch gerne jemand genommen, der faktisch nur die Entscheidungen umgesetzt hat (wie ein Programmierer die Entscheidungen des Vorgesetzten oder ein Projektleiter die Anforderungen des Kunden umsetzt).

Warme Leiche

Eine warme Leiche (englisch warm body) bezeichnet eine Person, die einen zweifelhaften oder keinen Beitrag zu einem Projekt leistet.

Beispiel

In frühen Entwicklungsphasen sollten wenige Spezialisten das System entwerfen, erst anschließend können mehr Entwickler in einer größeren Anzahl das System umsetzen. Zu viele Entwickler in frühen Phasen begünstigen warme Leichen.

Single head of knowledge

Ein Single head of knowledge ist ein Individuum, welches zu einer Software, einem Werkzeug oder einem anderen eingesetzten Medium, als einziges unternehmensweit das Wissen besitzt. Dies zeugt häufig von fehlendem Wissensmanagement, mangelndem Austausch zwischen den Kollegen oder rudimentären Defiziten in der Organisation, kann aber auch von dem Individuum bewusst angestrebt worden sein.

Wenn das Individuum die Unternehmung verlässt, nimmt es bildlich gesprochen das Wissen mit, was für die Unternehmung sehr gefährlich ist. Die Unternehmung blutet metaphorisch aus (bleeding).

Das Muster kann durch geeignete Maßnahmen verhindert werden. Beispielsweise durch Entwicklung nach XP und Teambuilding-Events zusammen mit Mitarbeiterbindung, Motivation und Förderung der Identifikation mit der Unternehmung, um die Fluktuation zu minimieren. Auch eine ordnungsgemäße Dokumentation, auf die alle betroffenen Mitarbeiter Zugriff haben, verhindert einen Single head of knowledge.

Mushroom management

Beim Mushroom management werden Mitarbeiter uninformiert und klein gehalten. Hierbei gelten die folgenden Grundsätze:

“Keep them in the dark and feed them full of shit.”

„Lass sie im Dunkeln und fütter sie mit Scheiße.“

– mushroom management. In: Urban Dictionary. Abgerufen am 31. Januar 2013. 

Entfaltung und Selbstverwirklichung finden beim Mushroom management kaum statt. Die Analogie der Belegschaft zu einem Pilzfeld zeichnet sich dadurch aus, dass die Mitarbeiter bildlich mit Mist bedeckt und im Dunkeln gehalten werden und, wenn sie zu groß geworden sind (zu viel Erfahrung, zu gute Leistungen, etc.), klein gemacht, unter Druck gesetzt oder gar entlassen werden. Diese Assoziation beinhaltet ferner die These, dass die Führung Entscheidungen fällt, ohne die Spezialisten zu konsultieren bzw. die Belegschaft über diese Entscheidungen nicht informiert. Häufig ist auch zu beobachten, dass das Management die individuellen Fähigkeiten, Stärken, Schwächen und Rollen der Teammitglieder nicht kennt und manchmal sogar auch nicht kennen will (Personen werden gleichgeschaltet: Zugeben, dass jemand mehr kann als die anderen, macht ihn mächtiger, was vermieden werden soll).

Noch ein Meeting mehr wird es lösen

Noch ein Meeting mehr wird es lösen (englisch Yet Another Meeting Will Solve It) bezeichnet es, wenn ein Meeting in einem verspäteten Projekt (d. h. ein Projekt mit Verzug) einberufen wird, wodurch sich der Verzug nur noch mehr erhöht.

Net Negative Producing Programmer

Ein Net Negative Producing Programmer ist ein unperformanter, unproduktiver Entwickler. Diesen aus einem Team zu entfernen kann die Projektproduktivität mehr erhöhen, als einen guten Entwickler hinzuzufügen und den unproduktiven zu belassen.

Management nach Zahlen

Management nach Zahlen (englisch Management by numbers) ist eine Anspielung auf Malen nach Zahlen. Beim Management nach Zahlen wird ein übermäßiger Schwerpunkt auf das quantitative Management gelegt. Insbesondere wenn Fokus auf Kosten gelegt wird, während andere Faktoren wie Qualität vernachlässigt werden.

Bei diesem Muster werden Programmierer gerne als „Gebrauchsgut“ (engl. commodity) gesehen und als austauschbar betrachtet. Sehr kurzfristige Denkweise, die außen vor lässt, dass fehlende Mitarbeitermotivation oder Mitarbeiterfluktuation dem Unternehmen mittel- bis langfristig wesentlich teurer kommen als eine kurzfristige Investition in diese.

Hier ist auch der Begriff der Softwarefabrik (Software Factory) anzuführen, der Versuch, die Softwareentwicklung zu automatisieren und den Programmierer als austauschbaren Produktionsfaktor zu betrachten. Dies berücksichtigt allerdings nur unzureichend, dass die Softwareentwicklung zu einem großen Teil ein kreativer, künstlerischer Prozess ist, der Freiraum und optimalerweise auch hohe Entfaltungsmöglichkeit sowie (optimalerweise intrinsische) Motivation des Entwicklers voraussetzt. Ferner gilt es zu bedenken, dass Mitarbeiter über die Zeit viel Erfahrung bei der Arbeit an einem Produkt aufbauen, die dem Unternehmen zu einem großen Teil verloren geht, wenn denn die Person die Unternehmung verlässt. Eine weitere Dimension ist die Unterscheidung zwischen Management nach „englischer Theorie“ und Management nach „spanischer Theorie“. Beim „englischen Führungsstil“ geht das Management davon aus, es gäbe nur eine feste Menge von Werten. Beim „spanischen Ansatz“ geht man davon aus, dass Werte durch Genialität und Technologie geschaffen werden können. Die Analogie dieser beiden Wertetheorien beruht auf Beobachtungen, wie die ehemaligen Kolonialmächte England und Spanien mit Ihren Kolonien umgingen, um maximalen Profit zu erlangen (die Spanier haben erkannt, dass ihr Vorgehen zu mehr Profit führt). Dem Muster kann durch einen Balanced Scorecard-Ansatz oder Management nach „spanischer Wertetheorie“ begegnet werden.

Angst vor Erfolg

Angst vor Erfolg (englisch Fear Of Success), auch Atmosphäre der Angst bezeichnet es, wenn das Management für eine verängstigte, defensive Atmosphäre sorgt. Dies gleicht einem Fußballteam, das nur das eigene Tor verteidigt, ohne Bestrebungen zu haben, selbst ein Tor zu schießen.

In einer Kultur voller Angst kann kaum etwas Konstruktives entstehen. Auch etwas Gutes erstellende Personen brechen ihr Vorhaben ab, weil sie davon ausgehen, dass sie sowieso verlieren oder die gute Lösung nicht honoriert bzw. als schlecht dargestellt wird.

Unternehmen unter Angst wirken gelähmt und versäumen es, neue Märkte und Lösungen aktiv anzugehen. Sowohl ganze Unternehmungen als auch Abteilungen oder einzelne Personen verlieren so ihre Wettbewerbsfähigkeit. Angst durch Erfolge aufzufallen und so den Argwohn der Kollegen oder des Managements auf sich zu ziehen, verhindert ebenfalls, dass Mitarbeiter und Unternehmungen ihre volle Leistungsfähigkeit abrufen. Nicht selten sehen schlechte Manager in sehr guten Angestellten eine Gefahr, da diese eine Konkurrenz auf ihre Position sind.

Typische Aussage: „Ich mache das heimlich. Es ist zwar die beste Lösung, ich will aber nicht, dass der Chef davon erfährt.“

Falscher System-Architekt

Ein falscher System-Architekt (englisch Faux System Architects) kann entstehen, wenn das Management erkennt, dass es bei den Fähigkeiten der Programmierer große Unterschiede gibt. Das Management sucht sich hierbei eine Person aus, die vermeintlich überwältigende Fähigkeiten hat, etwa sowohl bei der Software-Entwicklung als auch beim Umgang mit Leuten – gerade mit Personen, deren Qualifikation unterdurchschnittlich ist.

Die Person wird mit einer hohen Erwartungshaltung des Managements eingesetzt und ist häufig ein Architekt, oft aber auch ein anderer fachlicher Vorgesetzter. Bei der Auswahl werden interne Spezialisten nicht gefragt, sondern das Management entscheidet selbst und alleine, obwohl es nur schwer selbst entscheiden kann, ob jemand ein guter Software-Entwickler ist.

Lange Zeit läuft dies auch recht gut, da sich der vermeintliche Experte recht gut verkaufen kann und sich auch verbal sehr geschickt auszudrücken weiß. Über die Zeit wird aber immer deutlicher, dass die Erwartungen an den Architekten zu hoch waren. Einerseits an der nicht eingetretenen Verbesserung der Software oder der gleichbleibend schlechten Qualität der schlechten Programmierer, andererseits an einer Unzufriedenheit der guten Programmierer. Er kann die blumigen, fast blinden Erwartungen in ihn nicht erfüllen. Bei der Beurteilung des Systemarchitekten gilt es insbesondere immer das Projekt als ein Ganzes zu betrachten. So kann die gleichbleibend schlechte Qualität schlechter Programmierer sehr wohl auch in Umständen begründet sein, auf die auch ein guter Systemarchitekt absehbar keinen Einfluss nehmen kann. Gute System-Architekten können ihrer Position entsprechend auch Opfer von Body ballooning oder Empire building (s. o.) werden. Ein guter Systemarchitekt wird z. B. nicht über Wochen oder Monate hin versuchen, die Qualität schlechter Programmierer zu verbessern, wenn sich für ihn absehbar kein Potential erkennen lässt. Von einem schlechten Management vorgegebene unrealistische Rahmenbedingungen degradieren u. A. auch den besten Systemarchitekten. Sollten solche Umstände bekannt sein, der Systemarchitekt aber trotzdem keine Anzeichen machen, das Unternehmen zu verlassen, könnte es sich tatsächlich um einen schlechten Systemarchitekten handeln.

Crocodile Management

Beim Crocodile Management ist der Projektleiter nur teilweise im Projekt anwesend und kümmert sich nur um Details, die der Projektmitarbeiter nicht erledigt hat. Das Verhalten des Projektleiters kennzeichnet sich hierbei durch:

1. auftauchen
2. Maul aufreißen
3. abtauchen

Programmer Interrupt

Ein Programmer Interrupt liegt dann vor, wenn der Programmierer während seiner Arbeit unterbrochen wird. Hierzu gehören Äußerungen von Kollegen, E-Mails, anstehende Meetings und ähnliches. Studien zufolge benötigt ein Programmierer nach einer Unterbrechung zwischen 10 und 15 Minuten, um wieder effektiv weiterarbeiten zu können, bekommt aber nur etwa einmal am Tag die Möglichkeit, für mehr als zwei Stunden ohne Unterbrechung arbeiten zu können. Die Unterbrechung ist umso schwerwiegender, je höher die geistige Beanspruchung des Programmierers während seiner Tätigkeit ist.

Besonders problematisch sind hierbei Unterbrechungen

• während der Bearbeitung von mehreren Codeabschnitten gleichzeitig,
• während Suchaktivitäten zu Programmierproblemen,
• während des Durchdenkens des Programmablaufs; insbesondere bei parallelem Code,
• durch die der Entwickler die Integrierte Entwicklungsumgebung aus dem Sichtbereich verliert.

Typischerweise versuchen Entwickler möglichen Unterbrechungen mit Kopfhörern, dem Schließen des E-Mail-Programms und teilweise dem Abschalten des Mobiltelefons zu begegnen. Weitergehend wenden Entwickler Methoden an, um sich möglichst schnell wieder einarbeiten zu können, hierzu gehören To-do-Listen, bewusst hervorgerufene Compilierungsfehler (etwa durch Modultests) und Klebezettel.

Unterbrechungen des Arbeitsablaufs lassen sich jedoch nicht nur bei Entwicklern, sondern bei allen Büroangestellten beobachten.

Weitere

• Software verrotten lassen

Meta-Muster

Programmer Experience Clumping

Unerfahrene Programmierer sind meistens bereit, für eine relativ geringe Vergütung für ein Unternehmen zu arbeiten (z. B. aus Unwissenheit oder um dort Erfahrung zu sammeln). Häufig werden in solchen Unternehmen die Programmierer vom Management nicht geschätzt (meistens in Firmen, in denen Management by numbers vorherrscht). Es liegen schlechte Arbeitsbedingungen vor. Die unerfahrenen Programmierer können sich nicht weiterentwickeln. Erfahrene Spezialisten sehen, was passiert, und können dies objektiv und kritisch einschätzen. Diese werden den Arbeitsplatz wechseln, um eine Herausforderung anzunehmen, in der die Programmierung besser verstanden und gute Arbeit gewürdigt wird. Dies produziert einen Gruppierungseffekt, in dem sich unerfahrene Programmierer im Unternehmen gruppieren bzw. dort verbleiben, und die erfahrenen Leute sich woanders gruppieren. Es kommt zu einer hohen Fluktuation, bei der immer mehr gute Leute das Unternehmen verlassen. Ohne die Führung der erfahrenen Kollegen können die unerfahrenen Entwickler oder neu eingestellte Rookies sich nicht verbessern. Ein Teufelskreis entsteht, der auch dadurch verstärkt wird, dass der Arbeitgeber seine (vermeintlich weniger loyalen) Angestellten zu immer weniger Schulungen schickt, da er Angst hat, die Personen verlassen das Unternehmen sowieso und das Geld wäre fehl investiert. Irgendwann weiß niemand im Unternehmen mehr, wie ein erfahrener, guter Entwickler aussieht bzw. es fehlt der Benchmark: die unerfahrenen Entwickler merken immer weniger, dass sie eigentlich unerfahren sind. Programmer Experience Clumping ist nicht auf Programmierer beschränkt, auch IT-fremde Fachabteilungen können betroffen sein. Ein Derivat des Anti-Patterns ist, dass die guten Leute aus Bequemlichkeit oder anderen persönlichen Gründen zwar im Unternehmen verbleiben, ihre enorme Leistungsfähigkeit allerdings so drosseln, dass sie nur noch ein kleines Stück besser sind als die schlechten Mitarbeiter. Da dies ausreicht, um sich abzugrenzen und die Position zu sichern, schöpfen die guten Mitarbeiter bei weitem ihr Potential nicht aus. Dies ist letztendlich für alle Beteiligten, vor allem aber für das Unternehmen, sehr bedenklich.

Zersetzung

Eine Zersetzung (englisch Corrosion) bezeichnet die gewollte oder ungewollte Nutzung einer Vielzahl von Anti-Pattern aus allen Bereichen. Geht einher mit konsequenter Verteidigung des Vorgehens. Meist unsachlich und brachial, ohne Diskussion. Führt unweigerlich zu der Vermutung, der Anwendende möchte der Unternehmung oder dem Softwareprodukt grob fahrlässig Schaden zufügen bzw. dessen erfolgreiche, kostengünstige Einführung verhindern. Kann auch dadurch motiviert sein, dass der Anwendende einer anderen involvierten Partei schaden möchte.

Literatur

• Frederick P. Brooks: Vom Mythos des Mann-Monats: Essays über Software-Engineering. mitp, Bonn 2003, ISBN 3-8266-1355-4.
• William J. Brown et al.: Anti-patterns. Refactoring Software, Architecture and Projects in Crisis. John Wiley & Sons, New York 1998, ISBN 0471197130.
• Martin Fowler: Refactoring: Improving the Design of Existing Code. Addison-Wesley, Reading/Massachusetts 1999, ISBN 0201485672.
• Joshua Kerievsky: Refactoring to Patterns. Addison-Wesley, Boston 2004, ISBN 0321213351.
• Bruce A. Tate: Bitter Java. Manning, Greenwich/Connecticut 2002, ISBN 193011043X.
• Bruce A. Tate et al.: Bitter EJB. Manning, Greenwich/Connecticut 2003, ISBN 1930110952.
• Gerald M. Weinberg: Psychologie des Programmierers. mitp, Bonn 2004, ISBN 3-8266-1465-8.

Siehe auch

• Technische Schuld

Weblinks

• Anti-Pattern-Definition, Portland Pattern Repository (englisch)
• Anti-Pattern-Katalog, Portland Pattern Repository (englisch)
• Anti-Pattern Tutorial (englisch)
• Bruce Eckel: Programmer Experience Clumping und Faux System Architects (englisch)