Wider den Kompliziertismus!

Die Welt ist ein ungeheuer komplexer Ort.

Alle Dinge interagieren ständig aufgrund physikalischer, chemischer und evolutionärer Gesetze miteinander.
Die Interaktion zwischen Menschen ist mit enormen Komplexitäten behaftet.

Zwischen Menschen aus unterschiedlichen Kulturen, Ländern, Städten, manchmal sogar Stadtteilen und ganz sicher aus unterschiedlichen sozialen Herkünften gibt es enorme Unterschiede.Jeder Mensch ist anders. Jeder Mensch hat zeitabhängige Stimmungen.

Die Systeme, die wir in IT-Projekten bauen, sind manchmal ganz einfach. Als Modelle der physisch-technischen, sozialen oder kulturellen Wirklichkeit aber oft sehr, sehr komplex.

Schon kleinste Abweichungen im Verständnis oder der Definition eines Begriffs können weitreichende Folgen in der Systemmodellierung haben. Beispiel: Die Modellierung der Ehe in einem IT-System: Nur zwischen Mann und Frau? Zwischen gleichgeschlechtlichen Partnern? Jeweils wie vielen Personen welchen Geschlechts? In welchem Mindestalter? Was sind die damit verbundenen Rechtsgüter? Was, wenn die Ehe im Ausland geschlossen wurde, wo andere Regeln gelten? Welchen Einfluss haben gemeinsame voreheliche oder aus früheren Partnerschaften stammende Kinder? Spielt die kirchliche Trauung irgendeine Rolle?

Die Welt ist komplex, keine Frage.

Was ist die angemessene Reaktion darauf?

Einige Menschen blähen ihre Einschätzung jedweder Aufgabe grundsätzlich und systematisch auf. Komplex ist für sie das Gleiche wie kompliziert. Sie vermuten und berücksichtigen vorauseilend schon einmal alle denkbaren (und im Zweifel auch nicht denkbare) technischen, organisatorischen und fachlichen Komplikationen – und schlagen am Ende noch einen Risikoaufschlag drauf.
Wenn ein Satz in einer Anforderung komplizierter oder weniger kompliziert interpretiert werden kann, wählen sie immer die kompliziertere Interpretation. Sie wählen die kompliziertesten Architekturen und Implementierungsmuster, betreiben furchtlos das Aufhäufen technischer Schuld. Aufwands- und Preisabschätzungen treiben sie per Hau-den-Lukas in die Höhe, bis die Glocke klingelt.
Provokant formuliert: Komplexität wird zur Ideologie der Kompliziertheit, zum Kompliziertismus. Alles ist irre kompliziert und kaum beherrschbar, lasst es uns noch komplizierter machen.

Warum macht jemand das? Angst, die Aufgabe zu unterschätzen. Frühere schlechte Erfahrung. Überforderung, durch die ein paar Bäume wie ein großer, dunkler Wald aussehen. Viel Feind, viel Ehr. Geldschinderei gegenüber dem Kunden. Ressourcenschinderei gegenüber dem eigenen Chef. Vorauseilende Begründung für das eigene Versagen (“ich hab ja gleich gesagt, dass das irre komplizert ist”). Aufblähen der eigenen Wichtigkeit und demonstratives Zur-Schau-Stellen kritischen Denkens.

Einfachste oder zumindest in der Regel gut beherrschte Dinge werden so mühelos zu kaum überwindbaren Hürden, zu Sorgen, zu Angstbergen, zu Problemen.

Ich bin sehr erfolgreich mit dem gegenteiligen Ansatz. Ich glaube, dass es die Aufgabe von Projektleitern, Architekten und Beratern ist, die jeweils eleganteste und damit oft einfachste Lösung zu finden.

Ich gehe dabei oft zunächst von der naivstmöglichen Annahme aus. Wie würde die einfachste Lösung aussehen?
Natürlich bleibt die Lösung dann meist nicht so einfach. Ich schaue dann, welche zusätzliche Komplexität ich unbedingt berücksichtigen muss. So wird die Lösung Schritt für Schritt komplexer, aber in einer sehr kontrollierten Weise und nur auf Basis von verifizierten Annahmen.

Jederzeit beachte ich Vereinfachungsmöglichkeiten: Welche Anforderungen sind ähnlich und können generisch behandelt werden? Wo bestehen Anforderungen nur noch aus historischen Gründen, die heute eigentlich keine Bedeutung mehr haben?
Wo kommt die Anforderung überhaupt her? Wenn es niemanden mehr gibt, der weiß, warum es eine Anforderung gibt, ist sie vielleicht obsolet.

Oder als Scum Master/Agile Coach: Muss der Prozess wirklich so aufwändig sein? Muss wirklich eine monatelange Tool-Auswahl gemacht werden oder weiß das Team eh schon, welches der Sieger sein wird? Braucht es eine Earned-Value-Analyse oder reicht ein einfaches Burndown?Braucht es wirklich ein Zehn-Mann-Team oder wird nicht alles viel einfacher, wenn man zwei Fünf-Mann-Teams bildet? Hat das Sprint Commitment für dieses Team wirklich einen Mehrwert oder performt es auch ohne optimal?
Muss wirklich in Story Points geschätzt werden oder reichen Personentage?

Das Ziel: Die ohnehin schon komplexe Welt nicht ohne Not kompliziert machen.

 

Typologie von Software-Entwicklern (Teil 2): Der Ideologe

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.