Nach der Diva nun ein paar Charakterisierungen eines weiteren weit verbreiteten Entwicklertyps: des Ideologen.
Der Ideologe möchte, dass bei der Entwicklung einer Software alles richtig gemacht wird.
„Richtig“ heißt für ihn in der Regel, „dem höchsten Stand der Wissenschaft entsprechend“ – was immer er darunter versteht. Der Stand der Wissenschaft (hier: der theoretischen Wissenschaft) wird im Zweifel auch mal fix von ihm selbst definiert.
In der Regel besteht dieser „Stand der Wissenschaft“ aus einer Menge abstrakter Konzepte, die nur tendentiell auf das anstehende Problem anwendbar sind, weil hoffnungslos überdimensioniert.
Der Ideologe ist von dem Konzept, das er zuletzt neu verstanden hat, über alle Maßen überzeugt und strebt danach, es so konsequent wie möglich anzuwenden, nach dem Prinzip: Wenn ich Hämmer geil finde, ist jedes Problem ein Nagel.
Objektorientierung? Alles wird in so viele voneinander abgeleitete, winzige Klassen wie möglich zerlegt, bis zu dem Punkt, an dem manche Klassen nur noch aus Deklarationen und geerbten Eigenschaften ohne eigenen Code bestehen; bis der Code vor ellenlangen Bezeichnern mit geerbten, also implizit geforderten Parametern nur so wimmelt und jedes Debugging einem Doodle-Jump-Spiel mit vielen, vielen Ebenenwechseln ähnelt.
Interfaces? Alle Methoden einer Klasse dürfen nur noch über Interfaces aufgerufen werden, auch die trivialsten! Damit treibt man schön den Aufwand für die Signaturerstellung, muss ja alles doppelt gemacht werden…
Service Oriented Architecture? Jede Klasse ein Service, der per SOAP- oder REST-Protokoll mit den anderen Services redet, damit auch das letzte Quäntchen Performance irgendwo in den Netzwerk-Controllern verreckt. Aber alles so herrlich lose gekoppelt!
Projektstrukturierung? Der Theoretiker schafft es, so abstrakte Kategorien und Zerlegungen für jedes Schnipselchen der Software zu definieren, dass sich alle anderen Team-Mitglieder (und oft auch er selbst) in den Tiefen unendlicher und oft ungeeignete Zerlegungsdimensionen nutzender Ordnerhierarchien verlieren.
Verstehen Sie mich nicht falsch: All diese Konzepte sind toll und bei richtiger Anwendung sehr hilfreich. Nur eben dann nicht, wenn sie zur Ideologie werden („Am serviceorientierten Wesen soll mein Code genesen!“), um die herum Fragen wie Eignung, Angemessenheit und Verständlichkeit verbogen werden.
Die zweite irritierende Haupteigenschaft des Ideologen: Er möchte (und kann) seine Ideologie nicht unbedingt selbst umsetzen. Oft genug kann er es gar nicht, denn das reale Verständnis reicht über das Lesen von einen paar Artikeln im Web und ein bisschen „Spielen zuhause“ nicht hinaus!
Die Umsetzung können gern andere machen, solange sie dem Geist seiner Ideen folgen…
Wie die Diva kann der Ideologe ganze Teams lähmen, wenn ihm nicht genügend gesunder Entwicklerverstand entgegengesetzt wird, zum Beispiel deshalb, weil das Management seine Buzzwords für bare Münze nimmt und ihn als Experten für die neuesten Trends zum Verantwortlichen für Architektur oder den Software-Entwicklungsprozess macht.
Nein, man muss nicht die allerneueste Technologie verwenden, uns reicht es, gut funktioniernde Software zu bauen, deren Grundlage alle im Team gut beherrschen. Nein, Konsequenz ist nicht das höchste Prinzip, wohlfundierter, dem Problem und den Randbedingungen angemessener Pragmatismus ist es.
Was tun mit Ideologen? Lasst sie so lange ihre eigenen Ideen (nicht projektkritisch!) in Prototypen umsetzen und sich die Hörner daran abstoßen, bis sie sie von selbst verwerfen („toller Ansatz, aber unausgereift“) oder sie die nötige Zielorientierung entwickeln und das Ergebnis geläutert ins Team tragen können. Nicht alles, was ein Ideologe mitbringt, ist ja falsch oder auch nur schlecht. Nur die blinde Missionierung eines Projekts zum Glauben an untaugliche Techno-Gottheiten ist es.