Nur ein Gedanke …
Vor ein paar Tagen habe ich das folgende Zitat gelesen:
„Perfektion entsteht offensichtlich nicht dann, wenn man nichts mehr hinzuzufügen hat, sondern wenn man nichts mehr wegnehmen kann.“ (A. Saint-Exupéry)
Ich habe ein wenig darüber nachgedacht und bin für mich zu dem Schluss gekommen, dass eine Menge Wahrheit und Weisheit in diesem kurzen Satz steckt. Aber dann fing ich an, über die IT nachzudenken …
Man sollte denken, dass wir in Zeiten, in denen wir mit mehr und mehr Komplexität konfrontiert werden, nach dieser Art von Perfektion streben sollten, indem wir alles entfernen, das wir nicht unbedingt zur Erreichung unseres Ziels benötigen. Zumindest denke ich das. Schaue ich mich aber um, dann sehe ich die meiste Zeit das genaue Gegenteil davon. Wir stapeln mehr und mehr Komplexität um uns herum auf, egal ob wir sie benötigen oder nicht. Um einfach einmal ein paar Beispiele zu nennen:
- Um Dinge lückenloser gestalten zu können, erfinden wir jeden Tag ausgefeilte Templates für alle und jedes, beginnend mit superpräzisen Anforderungs-Templates und endend mit Support Prozessen, deren Beschreibung schon hunderte oder gar tausende Seiten dick ist … Templates und Regeln, die zu verstehen schon Wochen in Anspruch nimmt und die sicherstellen, dass der eigentliche Inhalt wesentlich schwerer zu verstehen ist als er es vorher war … zumindest für die „normalen“ Menschen.
- Um Unklarheiten zu vermeiden, erstellen wir Modelle, die eine ganze Wand benötigen um sie darzustellen. Kein Mensch versteht sie mehr in ihrer Gesamtheit, aber wir erstellen sie trotzdem. Und sollte das noch nicht ausreichen, erstellen wir zusätzlich Metamodelle und Meta-Metamodelle und stellen so sicher, dass wir die letzten paar Leute abhängen, die noch eine ungefähre Idee von dem Modell hatten.
- Wir versuchen, Dinge einfacher erledigt zu bekommen, indem wir Produkte einsetzen, die so viele Features haben, dass wir höchstwahrscheinlich niemals mehr als 3% davon nutzen werden … und wir integrieren solche Produkte auch noch in unsere Anwendungslandschaften.
- Um ein paar Tastendrücke zu sparen, packen wir so viel Zeug in unsere IDEs, dass niemand mehr weiß, was da alles im Hintergrund passiert und wir von der ganzen geschehenden „Magie“ regelmäßig ausgetrickst werden.
- Und ebenfalls in unserer niemals endenden Suche nach einfacherer Erledigung von Aufgaben erzeugen und nutzen wir so viele Frameworks, wie wir irgendwie in eine Anwendung gepackt bekommen. Als Ergebnis sind wir ununterbrochen damit beschäftigt, die ganze Technologie zu verstehen und die daraus entstehenden Integrationsprobleme zu lösen und haben überhaupt keine Zeit mehr, uns mit der eigentlichen Aufgabenstellung der Anwendung auseinanderzusetzen – Ihr wisst, dieses „Fachzeugs“.
- Mit all diesen Tools erzeugen wir dann Anwendung einer solchen Komplexität, dass niemand mehr wirklich versteht, was die Anwendung genau tut, weder die Anwender noch die armen Entwickler, die versuchen, irgendein ein neues Feature innerhalb dieses Code-Alptraums zu realisieren, ohne die ganze Anwendung kaputt zu machen.
- Und nur, weil wir es können und irgendjemand aus dem Fachbereich denkt, das könnte irgendwann einmal nützlich sein, verbinden wir alles und jedes in unserer Anwendungslandschaft miteinander, egal ob es irgendeinen Geschäftsnutzen hat oder nicht und erzeugen so ein Netz aus Abhängigkeiten, das keiner mehr so recht versteht.
Ich könnte noch stundenlang weitermachen, aber ich denke, Ihr wisst, was ich meine und Ihr könntet bestimmt wie aus der Pistole geschossen weitere Beispiele ergänzen. Wir schaffen es sehr oft, etwas eigentlich Einfaches in etwas Kompliziertes zu verwandeln, indem wir mehr und mehr Dinge hinzufügen, egal ob es dem Ziel dient oder nicht, bis es irgendwann komplexes Verhalten entwickelt, d.h. bis es unverständlich und unvorhersehbar in seinem Verhalten wird.
Bei unseren Versuchen, mit den Grenzen unserer Gehirne umzugehen oder manchmal auch nur aufgrund unserer Faulheit oder Angst vor Entscheidungen wählen wir sehr oft die schlechteste Alternative: Wir fügen Komplexität hinzu anstatt sie zu entfernen.
Wenn ich mir diesen Trend in der IT ansehe, dass alles immer komplexer und komplexer wird, denke ich mir, dass es an der Zeit ist, das Ruder herumzureißen. Anstatt über die wachsende Komplexität um uns herum zu jammern sollten wir versuchen, sie zu vermeiden, wo immer wir können. Um auch hier ein paar Beispiele zu nennen:
- Niemand zwingt uns, Dinge so formal wie Maschinen zu machen. Wir sind Menschen und wir sollten wie Menschen interagieren. Ja, wir machen Fehler (das ist Teil unserer Natur), aber wir machen insgesamt nicht weniger Fehler, wenn wir versuchen, uns wie Maschinen zu verhalten und so zu kommunizieren, d.h. immer formaler und formaler.
- Niemand braucht Modelle, die keiner versteht. Zuallererst dient ein Modell der Kommunikation, der Weitergabe von Wissen; und wenn niemand das Modell versteht, gibt es nichts weiterzugeben. Im Zweifelsfall bevorzuge ich ein einfaches Modell, das ich jedem problemlos erklären kann, anstatt ein komplexes Modell zu benutzen, das ich niemandem nahebringen kann, egal wie akkurat es ist.
- Niemand zwingt uns, jedes verfügbare Plugin in unserer IDE und jedes verfügbare Framework in unserer Anwendung zu verwenden. Vor vielen Jahren, als Design Patterns gerade „in“ waren, hatte ich einmal einen Kollegen, der uns eines Tages ganz stolz erzählte, dass er es geschafft hätte, alle Design Pattern des „Gang of Four“-Buches in seinen Code zu integrieren. Davon alarmiert hat sich der Rest des Teams seinen Code angeschaut. Das Ende vom Lied war, dass wir uns dazu entschlossen hatten, den gesamten Code wegzuwerfen, den der Kollege jemals für das Projekt geschrieben hatte und alles von Grund auf neu zu schreiben, weil der Code extrem fragil, voll von Fehlern und komplett unwartbar war. Das Gleiche gilt in der Regel für IDEs und Source Code, in denen zu viele Plugins, Frameworks oder was auch immer stecken.
- Und müssen wir wirklich unbesehen jede einzelne Anforderung umsetzen, die irgendein Fachbereichsmitarbeiter formuliert? Ja, es ist das ganz spezielle Recht eines Fachbereichs, beliebige Dinge anzufordern, ohne sich Gedanken über die möglichen technischen Konsequenzen zu machen. Es ist nicht ihre Aufgabe, sich darüber Gedanken zu machen und meisten verfügen sie dafür auch nicht über das benötigte Wissen. Aber es ist unsere Aufgabe, mit ihnen darüber zu reden, ihnen die Konsequenzen aufzuzeigen (bitte in einer nicht-technischen Sprache), ihnen Alternativen aufzuzeigen und ihnen zu helfen, die bestmögliche Entscheidung zu treffen, indem man ihnen hilft, das ganze Bild zu sehen. Meistens werden sie dann die beste Alternative wählen, und sehr oft ist das eine Alternative, die wesentlich weniger komplex ist als die initiale Anforderung.
Nun denn, dies ist keine „Schwarz oder Weiß“-Geschichte. Es gibt nicht „die“ Lösung für unser Problem und Vereinfachung bis zur Unbrauchbarkeit hilft auch nicht weiter. Aber ich denke, dass es an der Zeit ist, Komplexität zu vermeiden, wo immer wir sie nicht unbedingt benötigen, dass wir versuchen, uns zurück auf den Komplexitätslevel zu bewegen, den unsere Gehirne noch verarbeiten können. Oder, um dies mit einem weiteren Zitat zu beenden, das ich sehr mag:
„Weniger ist mehr!“ (Mies v.d. Rohe)
Wie ich bereits eingangs geschrieben habe: Nur ein Gedanke …
War dieser Beitrag hilfreich?
Weitere Beiträge
von Uwe Friedrichsen
16.10.2018 Dein Job bei codecentric?
Jobs
Agile Developer und Consultant (w/d/m)
Alle Standorte
Weitere Artikel in diesem Themenbereich
Entdecke spannende weiterführende Themen und lass dich von der codecentric Welt inspirieren.
Gemeinsam bessere Projekte umsetzen.
Wir helfen deinem Unternehmen.
Du stehst vor einer großen IT-Herausforderung? Wir sorgen für eine maßgeschneiderte Unterstützung. Informiere dich jetzt.
Hilf uns, noch besser zu werden.
Wir sind immer auf der Suche nach neuen Talenten. Auch für dich ist die passende Stelle dabei.
Blog-Autor*in
Uwe Friedrichsen
CTO
Du hast noch Fragen zu diesem Thema? Dann sprich mich einfach an.
Du hast noch Fragen zu diesem Thema? Dann sprich mich einfach an.