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 3): Der Dementor

Nach der Diva und dem Ideologen nun ein paar Worte zum Team-Mitglied-Typ “Dementor”.

In den Harry-Potter-Büchern gibt es geistartige magische Wesen namens Dementoren, die jedem, der in ihre Nähe kommt, die Lebensfreude absaugen, bis nur noch Verzweiflung, Düsternis und Qual übrig sind.

Frau Rowling hat diese Figur mitten aus dem Leben gegriffen und nur leicht übertrieben.

Manche Projekte oder Teams scheitern an Menschen, die wie wahre Dementoren wirken.

Macht keinen Sinn. Das funktioniert doch nicht. Boah ist das alles Mist. Das haben wir schon früher ohne Erfolg versucht. Das haben schon andere ohne Erfolg versucht. Ich hab soooo keinen Bock. Sorry, ich bin halt nicht sozialkompetent. Muss ich das wirklich machen? Ist doch alles Scheiße. Ich kann halt nicht pünktlich sein. Ich bin so genervt. Ist doch egal, ob wir fertig werden, interessiert doch eh keinen. Es ist doch eh alles egal. Das Management/der PO/der Scrum Master/irgendjemand ist doch voll bescheuert. Ich bin nicht fertig geworden, aber nach/vor X Uhr arbeite ich nicht. Natürlich ist das schief gegangen, was dachtest Du denn? Nimm halt nicht Windows! Hab ich mir schon so gedacht, dass das nichts wird. Das hätte ich Euch schon am Anfang sagen können. Was willst Du denn? Das kriegen wir niemals hin. Hm-hmmm. Klar kann ich gleichzeitig “Tank World” spielen und programmieren. Da mache ich nicht mit. Ihr habt doch alle keine Ahnung. Stöhn. Das hat dein Vorgänger auch schon versprochen… und wo ist er jetzt? Warum ich? Ich will nicht mit Dir reden. Murmel-murmel. Ja, wir waren irgendwie verabredet, aber ich hatte etwas Besseres zu tun.

Höhnisches Lachen, wenn jemand anderes etwas Positives oder auch nur Konstruktives äußert. Spielen mit dem Handy in der Besprechung. Füße auf dem Tisch. Mürrisches Gesicht. Jeder Handgriff wird diskutiert. Null-Bock-Körperhaltung. Der Blick immer knapp am Gesprächspartner vorbei. Bloß nicht lächeln. Provokativ langsames Reagieren auf oder gar Ignorieren von Ansprache oder Kritik. Augenrollen. Sarkasmus. Zynismus. Unleserlich schreiben. Spätes Kommen und frühes Gehen. Demonstrative Freude am Misserfolg.

Dementoren ziehen meine Lebensfreude ab.

Jetzt bin ich selbst deprimiert. Ist doch alles Mist.

Der Dementor steckt in jedem von uns.

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.

 

Typologie von Software-Entwicklern – Teil 1: Die Diva

Etwas Lustiges zum Einstieg:

Diven sind tödlich für Teams. Und das, obwohl sie meist individuell gut bis sehr gut sind. Manchmal ist diese Güte allerdings auch nur eingebildet. Sie sind sich ihrer tatsächlichen oder nur gefühlten Kompetenz sehr bewusst und sehr sicher. Alle anderen im Team sind tendenziell Idioten, vor allem der Projektleiter/Scrum Master/Product Owner, von dem sich eine Diva kaum etwas sagen lässt, und wenn, dann nur unter augenverdrehendem Protest.

Diese Arroganz versteckt die – übrigens meist männliche – Diva gegenüber den anderen Team-Mitgliedern in der Regel unzureichend, meist gerade so viel, dass man ihr nicht den Vorwurf der direkten Beleidigung machen kann, aber offen genug, um systematisch zersetzend zu wirken.

In Momenten besonderer Entnervtheit zeigt die Diva ungeschminkt ihr wahres Gesicht und zieht gegen das aktuelle Opfer mit voller rhetorischer und manchmal körpersprachlicher Wucht zu Felde. Kritik an ihrem Kommunikationsstil wird bestenfalls beleidigt angehört und grundsätzlich dem Idiotentum des Sprechers zugerechnet, niemals aber eigenen Verfehlungen.

Die Diva nimmt sich in technischen Belangen allen anderen als weit voraus wahr. Das Verwenden gut abgehangener, funktionierender Technologien wird oft abfällig und herablassend kommentiert. Es müssen die allerneuesten, dem Bisherigen theoretisch weit überlegene Technologien und Konzepte sein, unterhalb von “Cutting Edge” macht es die Diva nicht. Die mit diesen Neuerungen verbundenen Kinderkrankheiten, Unvollständigkeiten und sonstigen Schwierigkeiten betrachtet die Diva als Herausforderung und manchmal beherrscht sie sie sogar aufgrund ihrer überlegenen Sachqualifikation sogar – nur leider sonst niemand im Team.

So gut wie immer wirkt sich eine Diva negativ bis sehr negativ auf das Team aus. Zurecht ständig genervte, demotivierte und sich herabgesetzt fühlende andere Team-Mitglieder, zusammenbrechende Team-Kommunikation, ständige zersetzende Negativität gegen über allem, was nicht von der Diva selbst vorgeschlagen wurde, Monopolisierung von Know-how, passiv- oder aktiv-agressives Verhalten und von der Diva durchgesetzte technische Abenteuer sind nur die Spitze des Eisbergs.

Dennoch tun sich Unternehmen sehr schwer damit, Diven aus Teams oder gleich komplett aus der Organisation zu entfernen: Sie sind ja so gut. Man ist so abhängig von ihnen, wegen des Spezialwissens. Selbst wenn die Diva ein ganzes Team mehr oder weniger lahmlegt, erste Teammitglieder um Versetzung bitten oder gar kündigen, wird die Diva kaum jemals als Ursache wahrgenommen.

Ich sage: Diven nach maximal zwei ignorierten Warnschüssen entweder auf nicht unternehmenskritische Einzelaufgaben setzen oder ihnen die Gelegenheit geben, ein anderes Unternehmen zu ruinieren, vorzugsweise einen Konkurrenten.

Nächste Folge: der Ideologe.