Perfektion in der IT – oder „weniger ist mehr“

22 Kommentare

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 …

Uwe Friedrichsen

Uwe Friedrichsen ist ein langjähriger Reisender in der IT-Welt. Als Fellow der codecentric AG ist er stets auf der Suche nach innovativen Ideen und Konzepten. Seine aktuellen Schwerpunktthemen sind Skalierbarkeit, Resilience und die IT von (über)morgen. Er teilt und diskutiert seine Ideen regelmäßig auf Konferenzen, als Autor von Artikeln, Blog Posts, Tweets und natürlich gerne auch im direkten Gespräch.

Share on FacebookGoogle+Share on LinkedInTweet about this on TwitterShare on RedditDigg thisShare on StumbleUpon

Kommentare

  • Ben Hill

    20. April 2010 von Ben Hill

    Perfect is the enemy of good – Voltarie

    Now, defining what is good enough….

  • Uwe Friedrichsen

    @Ben: Yup, you hit the bull’s-eye: What’s good enough?

    I’m only afraid that this will be the second step. Imho the first step is to wake up and to avoid (unnecessary) complexity instead of piling it up higher and higher …

    Whenever we will have learned that lesson by heart, we will be ready to take the next step and figure out what’s good enough. I think the real „perfection“ in our business is hitting the „good enough“.

    Don’t get me wrong: I know there are some people who have a good feeling for what’s good enough but I only find them occasionally. Most of the time I see people who try to improve control by adding complexity … but maybe I’m just looking in the wrong direction … 😉

    Regards, Uwe

  • Marco Martienssen

    Ich habe den Eindruck, dass das sogar ein Merkmal unser Zeit ist und nicht nur die IT betrifft. Egal wo man hinblickt, in nahezu allen Lebensbereichen findet sich dies „mehr“ wieder. Welches Produkt kommt heute noch ohne Zusatzfunktionen aus? Autos haben Dispays in Kopfstützen (und verbrauchen immer noch viel Energie), Mobiles sind mit Kameras ausgestattet (und immer noch selten intuitiv zu bedienen), Geschirrspülreiniger hat mindestens sieben Funktionen, etc.

    Das es anders gehen kann, zeigt aus meiner Sicht Apple relativ erfolgreich. Anstatt ständig neue Funktionen hervorzubringen wird zunächst einmal alles weggelassen, was nicht dem eigentlichen Zweck entspricht (wie z.B. eine Maus mit nur einem Button). In der Folge werden alle Kräfte dann darauf verlegt, die Funktionen des Gerätes oder der Software für den eigentlichen Zweck zu optimieren. Ohne Rücksicht auf Altsystem, Standards und scheinbar absolut zwingende Funktionen (siehe cut&paste beim iPhone). Im Ergebnis entsteht ein Produkt, dessen Funktion sich dem Nutzer direkt erschließt.

    Die Weiterentwicklung erfolgt in mehreren evolutionären Schritte, wobei die Kernfunktionalität nie aus dem Blick gerät. So fügen sich Funktionen ein, die zunächst weggelassen wurden, um die Kernfunktionalität in den Fokus zu rücken (siehe bspw. Magic Mouse).

    Ich denke schon einige Zeit darüber nach, ob diese Vorgehensweise nicht auch in IT-Prozessen & -Projekten der bessere Weg wäre. Nach dem Motto – reduced to the max!

  • Uwe Friedrichsen

    Hallo Marco,

    guter Kommentar, auch wenn die Diskussion durch die Erwähnung von Apple jetzt religiöse Züge anzunehmen droht … 🙂

    Es ist absolut korrekt, dass diese Fixierung auf immer mehr Features (und der damit verbundenen Komplexität) nicht nur auf die IT beschränkt ist, sondern sich in allen möglichen Bereichen unseres Lebens wiederfindet … und das nur selten mit dem Effekt, dass sich die Lebensqualität für die Betroffenen dadurch erhöht. Man könnte sich jetzt fragen, ob wir IT-ler den Feature- und Komplexitätswahn in den Rest der Welt getragen haben oder ob wir ihn schlicht von dort übernommen haben, aber das ist letztlich wohl müßig.

    Wenn ich mir ansehe, in welcher Komplexität wir uns regelmäßig voller Begeisterung wie die Lemminge ertränken, egal ob auf fachlicher, technischer oder organisatorischer Ebene, egal ob notwendig oder nicht, dann denke ich, dass es einfach wichtig ist, zumindest die nicht notwendige Komplexität herauszuwerfen … und das ist deutlich mehr, als man denkt.

    Das von Dir vorgeschlagene Vorgehen ist sicherlich ein guter und sinnvoller Weg in diese Richtung, bedeutet aber, dass eine Menge Leute umdenken müssen: Die Fachseite, die Projektleiter, die Manager und insbesondere auch wir IT-ler … und das ist kein fachliches oder technisches Thema, das hat mit Veränderung zu tun … schwierig, schwierig … 😉 … aber wichtig!

    Gruß, Uwe

  • Andreas Ebbert-Karroum

    Spiegel Online hat im Februar übrigens einen Artikel gebracht, der die Thematik von der persönlichen Perspektive beleuchtet:

    Optimierungswahn – Fluchtwege aus der Perfektionsfalle

    Der Einzelne dagegen droht sich in den Paradoxien der Perfektionierung zu verheddern, wenn er versucht, allen möglichen Ansprüchen gerecht zu werden, mit dem Ergebnis, dass er nichts richtig kann.

    In dem Artikel wird diskutiert, woher unsere Neigung zum Perfektionismus kommt, und zeigt eventuell Wege aus dieser „Perfektionsfalle“ auf.

  • Uwe Friedrichsen

    Hallo Andreas,

    interessanter Artikel. Er geht zwar in eine andere Richtung als das, worüber ich geschrieben habe, aber vielleicht hilft die in dem Artikel empfohlene persönliche Einstellung, auch besser das „richtige Maß“, das „Good enough“ in dem von mir besprochenen Thema zu finden … das könnte ich mir zumindest sehr gut vorstellen.

    Gruß, Uwe

  • Niklas Schlimm

    21. April 2010 von Niklas Schlimm

    Hi Uwe,

    in dem ersten Zitat steckt ja der Gedanke einen definierten Nutzen mit geringstmöglichen Mitteleinsatz zu erreichen. Das ist ein ökonomisches Prinzip (hier Minimalprinzip) das zumindest BWLer in ihrer ersten Vorlesung hören. Es wird weit verbreitet auch verfolgt, sonst würden die Unternehmen der Reihe nach Pleite gehen. Damit meine ich, das auch die IT weit verbreitet dieses Prinzip verfolgt, soweit si nach ökonomischen Prinzipien handelt.

    Ich verstehe den Zusammenhang von Perfektion und Komplexität nicht. Komplexität ist ja seit je her das Hauptproblem der Datenverarbeitung und entsteht unabhängig davon ob etwas subjektiv/objektiv perfekt ist.

    Komplexität entsteht nach meiner Erfahrung im Normalfall aus drei Gründen (kommt oft in Kombinationen vor):
    (1) das Problem ist komplex. Dann ist notwendigerweise auch die EDV Lösung komplex.
    (2) das Problem ermöglicht viele verschiedene Lösungen und die Wahl der richtigen Alternative ist deswegen komplex, weil man so viel verstehen muss
    (3) die Lösung wurde komplex umgesetzt bzw. es wurde sich für einen komplexen Lösungsweg entschieden. D.h. die Lösung ist nicht intuitiv nachvollziehbar.

    Deine Grundaussage Komplexität wann immer möglich zu reduzieren unterstütze ich absolut.

    Gruss
    Niklas

  • Uwe Friedrichsen

    Hallo Niklas,

    ein sehr interessanter Kommentar!

    Ich fange mal in der Mitte an: Es geht nicht um Perfektion (die ist für uns Menschen doch eh nicht erreichbar … 😉 ), es geht um die Komplexität, mit der wir uns umgeben. Das Zitat war ja nur der Ausgangspunkt der folgenden Gedanken, weil es die Vereinfachung als erstrebenswerten Weg darstellt.

    Damit kehre ich zurück zum Anfang Deines Kommentars: Deiner Aussage dort kann ich aus dem, was ich immer wieder beobachte, nicht wirklich zustimmen. Eine stringente Umsetzung des ökonomischen Prinzips kann ich an vielen Stellen nicht erkennen. Es wird häufig (nicht nur in der IT) „viel zu viel“ gemacht, was dann wieder durch „viel zu wenig“ kompensiert wird. Statt einer geradlinigen Anwendung des in der ersten Vorlesung Gelernten findet man ein mehr oder minder hektisches Hin und Her zwischen den Extremen.

    Pleite geht ein Unternehmen, wenn es mehr ausgibt als es einnimmt (oder keinen rettenden Investor mehr findet). Damit haben wir aber noch keine Aussage darüber, ob das Unternehmen seine Mittel ökonomisch optimal eingesetzt hat und alle Blind- und Fehlleistungen vermieden hat. Es hat nur genug eingenommen, um seine Ausgaben zu decken. (Anmerkung am Rande: An den effizienten, selbstregulierenden Markt glaube ich spätestens seit der Bankenkrise nicht mehr wirklich; den üblichen Folgegedanken brauchen wir also nicht weiterzuspinnen … 😉 )

    Damit springe ich zum Ende Deines Kommentars: Es ist m.E. wichtig, notwendige und nicht notwendige Komplexität zu unterscheiden. Die notwendige Komplexität einer Lösung ist die, die man benötigt, um die zugrundeliegende Aufgabenstellung angemessen umzusetzen. Alles weitere ist eine unnötige Verkomplizierung, ganz im Sinne von Einsteins Zitat „So einfach wie möglich. Aber nicht einfacher.“

    Anders ausgedrückt: Um ein gewisses Maß an Komplexität kommen wir schlicht nicht herum und darum geht es mir auch nicht. Aber das, was wir uns „on top“ regelmäßig noch „antun“, dagegen sollten wir etwas tun … und ich glaube, gerade auch in der IT finden wir da eine Menge Stellen auf allen Ebenen, an denen wir ansetzen können.

    Gruß, Uwe

  • Niklas Schlimm

    21. April 2010 von Niklas Schlimm

    Hallo Uwe,

    mir gefallen insgesamt zwei Dinge an Dem Blog nicht: (1) er klingt so als würden „die da draußen Ihre Arbeit nicht gut machen“, (2) Du stellst unstrittig richtige Aussagen in den Raum (sog. „Motherhood-Statements“), sparst aber an klaren Handlungsanweisungen, wie man zum Beispiel das notwenige Maß an Komplexität findet.

    Welche Komplexität ist „notwendig“? Das Problem ist doch unlösbar. Ein Problem immer mit dem richtigen Maß bzw. mit der notwendigen Komplexität zu lösen schafft man doch wenn überhaupt nur unter Laborbedingungen. Über die gesamte Laufzeit einer Software-Lösung schleicht sich möglicherweise Schritt für Schritt aufgrund verschiedener Ursachen immer mehr Komplexität ein. Folgende Einflussfaktoren seien genannt:

    (1) Am Anfang entwirft man ein System und alles ist oft noch super einfach gelöst. Dann kommen verrückte Anforderungen, die nicht ins Konzept passen …
    (2) Der pathologische Zeitdruck unter dem man im Projekt leidet nicht immer ein Hilfsmittel um die einfachste Lösung zu wählen.
    (3) Oft ist man unter bestimmten Rahmenbedingungen gezwungen eine kompliziertere Produktlösung zu wählen (manche Firmen haben feste Verträge mit IBM, Sun, Oracle etc.).
    (4) Oder auch Häufig: Der eine Manager präferiert einfach grundsätzlich eine bestimmte Produktpallette einer bestimmten Firma.

    Was jetzt? Ich will nur sagen: die da draußen arbeiten immer unter bestimmten Gegebenheiten. Und nach meiner Erfahrung gibt es immer nachvollziehbare Gründe, warum etwas nicht optimal bzw. zu komplex gelöst wurde. Die Aufforderung ansich Komplexität zu reduzieren und wann immer möglich nur das notwendige Maß zu finden hilft mir aus praktischer Sicht einfach nicht weiter. Du läst einfach viel zu viel offen.

    Streiten wir uns? 🙂

    Grüsse
    Niklas

  • Niklas Schlimm

    21. April 2010 von Niklas Schlimm

    Hallo Uwe,

    mir sind noch zwei Punkte zur Ergänzung eingefallen, die es erschweren in der Praxis das „notwendige Maß an Komplexität“ zu finden:

    (5) Bewegungen wie agile Software-Entwicklung versuchen irreversible Architekturentscheidungen durch flexible Lösungen zu umgehen. Flexible Lösungen sind aber doch meistens komplexer als „unflexible Lösungen“, oder?
    (6) Komplexität ist immer auch eine zum Teil subjektive Empfindung, die zum Beispiel auch vom IQ des Betrachters abhängt oder von seinem Erfahrungsschatz, seiner persönlichen IT Laufbahn etc. Die einen würden deswegen zum Beispiel immer Hibernate als einfache Persitenzlösung präferieren, während andere ihren OO-ER Mapper lieber selbst bauen, weil sie Hibernate nicht kennen.

    Vielleicht ist erstmal die Kernfrage, was Software oder IT überhaupt komplex macht. Oder was wir grundsätzlich unter Komplexität verstehen.

    Vielleicht lohnt sich hier mal ein gemeinsamer Artikel? 🙂

    Gruss,
    Niklas

  • Uwe Friedrichsen

    Hallo Niklas,

    nein, „streiten“ würde ich nicht sagen, „reiben“ vielleicht, aber das ist ja gut und dafür sind Diskussionen da … 🙂

    Dann wollen wir uns mal weiter reiben …

    Zunächst einmal: Ich glaube eher an ein „wir“ als ein „die da draußen“, sprich ich nehme mich da in keinster Weise aus. Natürlich mache ich Beobachtungen eher bei anderen Leuten, was aber an der sehr menschlichen Eigenschaft liegt, dass man „den Balken vor dem eigenen Auge“ immer sehr schlecht sieht. Deshalb gebe ich mich aber nicht der Illusion hin, dass ich nicht die gleichen oder vielleicht sogar noch schlimmere Fehler wie „die anderen“ mache.

    Jetzt zu den „Motherhood-Statements“: Nun, dazu gibt es zwei Dinge zu sagen. Zum einen ist es erst einmal nur ein Gedanken, vielleicht ein Denkanstoß, den ich da formuliert habe, der schon so viel zu lang geworden ist. Wenn ich jetzt noch mehr konkrete Handlungsanweisungen als die wenigen Andeutungen in der zweiten Aufzählung hereingenommen hätte, dann wäre das einfach zu lang geworden. Aber ich bin bei Dir, da sollten prinzipiell noch Handlungsempfehlungen folgen. Das ist aber Thema weiterer Blogs oder Artikel.

    Damit sind wir auch schon beim zweiten Punkt: Man kann sicherlich einige sinnvolle, konkrete Handlungsempfehlungen geben. Nur ist jeder Projekt- und Systemkontext aus meiner Erfahrung recht spezifisch, so dass es schwierig ist, allgemeingültige Empfehlungen zu formulieren. Man läuft da aus meiner Erfahrung schnell Gefahr, starre Dogmen zu formulieren, wo eine einfache Idee in den Köpfen der Leute besser gewesen wäre. Aber ich schaue mal, was ich hinbekomme. In unserem Meet the Experts Architektur im September wollte ich das Thema aufgreifen.

    Letztlich zu Deiner Beschreibung, wie sich die Komplexität in Projekte und Systeme einschleicht: Yep, d’accord … habe ich auch schon in der ein oder anderen Form erlebt und häufig haben wir gar nicht die Möglichkeit, das wirklich zu beeinflussen.

    Mir geht es aber mehr um die Stellen, auf die wir Einfluss haben … Stellen, an denen wir zwischen verschiedenen Alternativen wählen können und aus welchen Gründen auch immer (Coolness-Faktor, Wollte-ich-immer-schon-mal-machen, Sieht-toll-auf-dem-Lebenslauf-aus, Unsicherheit, Unwissenheit, … warum auch immer, ist gar nicht böse gemeint, passiert schneller, als man glaubt) die kompliziertere Alternative wählt oder die vermeintlich einfachere Alternative, die die Gesamtlösung aber komplexer macht als die andere Alternative.

    Vor den von Dir beschriebenen Einflussfaktoren können wir uns nicht wirklich „schützen“. Da können wir als guter Kommunikator evtl. noch etwas bewegen, aber das war’s. Damit müssen wir „leben“ und umgehen.

    An den anderen Stellen liegt es an uns, was wir daraus machen und da sehe ich halt immer wieder einen Hang zur „Featuritis“, zu „Viel hilft viel“, zu „Nur neu ist cool/gut“.

    Und zu dem Thema habe ich mal meine ganz allgemeinen Gedanken formuliert, sozusagen als möglichen Denkanstoß … mehr hatte ich an der Stelle gar nicht vor … 😉

    Gruß, Uwe

  • Uwe Friedrichsen

    Hallo Niklas,

    jetzt ist die Reihenfolge durcheinandergeraten, weil Du einen Nachtrag geschickt hast, bevor ich mit der Antwort auf Deinen vorherigen Kommentar fertig war … 🙂

    Also hier die Antwort zum Nachtrag: Yep, sollten wir auf jeden Fall weiterverfolgen.

    (Meine Antworten können ja nicht immer länger als Deine Kommentare sein … 🙂 )

    Gruß, Uwe

  • Niklas Schlimm

    21. April 2010 von Niklas Schlimm

    Hi Uwe,

    Du sprichst auf jeden Fall zentrale Themen an 😉
    Ich kann mich da nicht zurück halten.

    Bis bald.

    Niklas

  • Shubhashish

    21. April 2010 von Shubhashish

    I don’t know about the rest of the comments. But at certain point i m agree with you that just to add something which can be done simply but sometimes we take a roundabout approach to do so and of course it hits performance and complexity at its best.

    I don’t know whether such things can be avoided or not.Or is there any way to measure how much complexity we introduce in our code base or subsystem. to cite an example, few days ago i confronted a code base where they have used the spring aop to do the logging and tracing. I mean that can be done simply by adding a logger to that class.

  • Uwe Friedrichsen

    @Shubhashish: Thanks fpr your comment!

    I don’t know either if we really can avoid such things or not. I think sometimes they will just happen for one reason or another. But the least we can do is to have the „idea“ back in our mind when we have to make decisions. From my experience an appropriate perspective on things combined with a bit of common sense is more helpful than the most elaborate rule set about how to do things … 😉

    Regards, Uwe

  • Mirko Novakovic

    Hallo Uwe, hallo Niklas,

    möchte mich jetzt auch mal mit „reiben“ 🙂

    Meiner Meinung nach ist eines der größten Probleme von uns Architekten, dass wir häufig dazu tendieren für konkrete Probleme generische Lösungen zu schaffen. Entkoppelung, Wiederverwendbarkeit etc. sind dann häufig das Argument für diese Ansätze. Vielleicht aber auch eine fachliche Anforderung, die wir am Horizont gesichtet haben. Diese Generik führt dann sehr häufig zu einer Komplexität, die für Entwickler nur noch schwer „sauber“ umzusetzen ist.

    Ich glaube, dass wir uns viel stärker darauf konzentrieren sollten die konkreten Probleme in einem Projekt mit unserer Architektur zu adressieren – das ist für mich „weniger ist mehr“.

    Zudem sollte man keine Angst haben Dinge auch mal wieder zu verwerfen. Oft entsteht Komplexität nur, weil man mal eine Fehlentscheidung getroffen hat (selbst ich mache das manchmal :-)) und diese nicht frühzeitig korrigiert.

    Übrigens hilft mir Agilität bei beiden Punkten:

    a) Weil ich mich auf den wichtigsten Geschäftsnutzen konzentrieren kann (muss).

    b) Weil mir kurze Iterationen helfen Fehler schnell zu sehen und die Feedback Schleifen verkürzt werden.

    Mirko

  • Uwe Friedrichsen

    Hallo Mirko,

    was soll ich dazu sagen? Ja, absolut d’accord!

    Sorry für das „Nichtreiben“ … 🙂

    Gruß, Uwe

  • Niklas Schlimm

    22. April 2010 von Niklas Schlimm

    Hallo Leute,

    ich muss mich aus Prinzip reiben, da ist mehr eben mehr 🙂 … also Ihr wisst schon 🙂 (ich wackel gerade mit meinem Armen tanzschrittartig neben meinen Hüften, der Mirko kanns Dir vormachen, Uwe … :-))

    Absatz eins: In modernen Projekten würde ich eher auf Framework Einsatz bauen. Frameworks kommen mit einem riesen Rucksack generischer Lösungen für konkrete Probleme, da muss ich weniger selbst bauen. Das heist aber vielleicht auch, dass die „eigenen“ generischen Lösungen abnehmen und das deswegen immer weniger Hebel zur Verminderung der Komplexität besteht … Außerdem ist der Gedanke agiler Ansätze ja gerade flexible Lösungen zu schaffen, das bedeutet generisch, das bedeutet eher komplex … Nochmal kurz: Komplexität entsteht aufgrund der großen Technologievielfalt und unserem (agilen) Versuch strategische Architekturentscheidungen zu vermeiden (=> durch flexible Lösungen).

    Absatz zwei: Bin absolut dabei. 🙂 Dumdiedumm … aber schön waren die Projekte schon, wo man neue Technologien ausprobiert hat, oder? Die eine neue Technologie, die wir mal ausprobieren wollten …. Ich werds kontrolliert weiter so machen (d.h. nach Abwägung der Vor- und Nachteile, Chancen/Risiken). Ich finds einfach geil neues auszubrobieren und kann deswegen bei manchen Punkten tatsächlich erst am Ende bewerten, ob ich das Problem adäquat gelöst habe. Einmal hatte ich großes Glück, zum Beispiel mit Rule Engines, ein anderes mal hatte ich eher pech, zum Beispiel mit generischen Vertragsobjekten im Vertragsmodell bei einem Einspartenversicherer mit drei Tarifen (wackel gerade wieder mit den Armen und schmunzel dabei all jenen zu, die das wieder umgebaut haben 😉 Danke Christian U.) Es läst sich einfach vorher so schwer abwägen, was adäquat, welches Problem löst.

    Absatz drei: Ja, korrigieren tue ich auch oft. Aber manchmal kann man nicht alles korrigieren, weil man nicht alles selber baut oder beeinflussen kann. Das übersteigt dann einfach den eigenen Aktionsradius. Wenn ich selbst was angehe korrigiere ich ich auf meinem Weg oft vieles „um mich herum“, wo ich denke, „dass muss ich jetzt mal grade rücken“. Aber das kann niemand für ein ganzes großes Projekt leisten. Und nicht jeder sieht mit den eigenen Augen, ob eine bestimmte Lösung der Korrektur zur Komplexitätsreduktion bedarf. Der Blick öffnet sich wenn überhaupt erst nach ner Menge schmerzhafter Erfahrung 😉 Trotzdem, Refactoring ist ein wichtiger Erfolgsfaktor. Ganz klar. Wirft aber wie beschrieben neue Probleme auf. Auch das Problem des fehlenden Verständnisses im Management, das man was funktionierendes nochmal umbauen möchte, damit nicht alles außer Kontrolle gerät. Ein Kollege hat mir hierzu mal ein interessantes Gleichnis mit gegeben: Ein Mann steht vor einem Berg und will auf die andere Seite. Er muss nur einen Stein mit nehmen, also entscheidet er sich über den Berg zu gehen, anstatt außen herum. Während seiner Tour werden dem armen Mann aber immer mehr Steine aufgebrockt, sodass er keinen Meter mehr bergauf gehen kann. Deswegen muss er umkehren und doch den Weg außen herum gehen ….

    Absatz vier: Der Absatz kommt aus Deiner Abilitätsbibel, oder? 😉 Jaaaaa, „Agilität“ …. alles wird gut 😉 Ich finde beide Punkte stammen im Kern nicht aus der Agilitätsbewegung. Kurze Kontrollzyklen waren schon in meinem Studium (das ist leider lange her) das Mittel der Wahl um die Probleme im Wasserfallmodell zu lösen. Grady Booch hat in seinem OOA/OOD Buch 1994 schon drüber gesprochen, andere OOler auch … die 80/20 Regel ist auch älter als Agilität. Ist wie bei SOA. Einzelerkenntnisse unter neuem Decknamen? Bin aber auch ein Scrum, FDD und XP Fan 🙂 Ich fühl mich in den Projekten einfach wohl. Und es ist ein Sammelsurium von Bestpractices …

    Bis dann
    Niklas

  • Steven Baumberger

    hi uwe,

    komplexität an sich ist ja erst einmal nichts schlimmes und tut auch nicht weh.
    je mehr elemente, beziehungen und funktionalitäten in einem system stecken, je komplexer wird es.
    man kann einem system nun mehr elemente, beziehungen oder funktionalitäten spendieren, als gefordert.
    das kann durchaus sinn machen (wartbarkeit, zukunftssicherheit etc.), diese art komplexität darf aber nach aussen nicht sichtbar werden.
    hat dies aber zur folge, das der kunde nun mit einer höheren komplexität konfrontiert wird als gewünscht, hat man sein projektziel nicht erreicht.
    mehr ist in diesem fall genauso falsch wie weniger.

    es stellt sich also eher die frage nach dem sinn der elemente, beziehen und funktionalitäten.
    die anzahl spielt eigentlich keine rolle.

    im produktgeschäft ist es deshalb auch so schwer, genau die wünsche der konsumenten zu treffen, jeder hat andere vorstellungen.

    viele grüße
    steven

  • Uwe Friedrichsen

    @Niklas: Du kannst es nicht lassen, oder? … 😉 … ich muss mich jetzt kurz fassen, weil ich mir hier schon genug Lästereien meiner Kollegen über die Menge und Länge der Kommentare anhören muss … 🙂 … deshalb nur die eine kurze Anmerkung: Frameworks und Produkte sind sicherlich sinnvoll, bergen aber auch Risiken: Zum einen bekommt man häufig wesentlich mehr als man eigentlich benötigt, was gar nicht so selten irgendwann zu – meist unerwarteten – Problemen führt und zum anderen multiplizieren sich die Lernkurven und Einarbeitungsaufwände mit jedem zusätzlichen Framework. Ergo: Ja, es macht keinen Sinn, das Rad jedes mal wieder neu zu erfinden, aber „umsonst“ ist das auch nicht. Die Verwendung eines Frameworks ist also nicht _automatisch_ „gut“ … vorher mal kurz drüber nachdenken, ob ich das wirklich brauche und was ich mir damit zusätzlich einfange, was ich eigentlich nicht benötige, ist schon sinnvoll … 😉

    @Steven: Hi, schön mal wieder von Dir zu hören! Dass Dir Komplexität nicht oder nur recht wenig weh tut, hast Du ja schon häufig eindrucksvoll bewiesen … 😉 … ich bin da allerdings mittlerweile etwas zurückhaltender geworden, weil ich halt immer wieder beobachten musste, dass es zum einen nicht allen Leuten so geht wie Dir und zum anderen gerade „vermeidbare Komplexität“ (ja, ich weiß, dass ich dafür noch eine Definition schuldig bin … 😉 ) häufig dazu führt, dass Leute so sehr auf „Nebenkriegsschauplätzen“ gebunden sind, eben um diese Teile zu verstehen, dass sie die wirklich wichtigen Teile gerne einmal aus den Augen verlieren.

    Ich bin bei Dir, dass die Menge an Komplexität, die man einem System „spendiert“, von verschiedenen Faktoren und Abwägungen abhängt, nicht nur von den reinen fachlichen Anforderungen und dass eine gewisse Menge an Komplexität in der Regel gar nicht vermeidbar ist (von den speziellen Problemen des Produktgeschäfts einmal ganz zu schweigen, wobei sich das Thema m.E. auf einer anderen Ebene bewegt). Mir geht es auch nur um einen kritischen Umgang mit dem Thema, nicht leichtfertig die Komplexität erhöhen („Lass uns das mal hereinnehmen, könnten wir vielleicht noch einmal brauchen“, „Nimm mal rein, wollte ich schon immer mal ausprobieren“ oder so), sondern sich immer die Frage stellen „Brauche ich das wirklich?“ … und wenn ich dann trotz kritischer Betrachtung zu einem „Ja“ komme, dann ist das auch in Ordnung.

    So, jetzt muss ich Schluss machen, sonst hagelt es hier wieder Lästereien … 🙂

    Gruß, Uwe

  • Roger Hann

    18. Oktober 2010 von Roger Hann

    Wer kann das bewerten/entscheiden?
    Wie lange dauert es, das zu bewerten/entscheiden?
    Wie lange ist diese Bewertung gültig?

    Und: sollte man diesen Blog-Eintrag nicht auch in diesem Lichte sehen.

  • Uwe Friedrichsen

    Hallo Roger,

    Deine Fragen sind absolut valide und ich denke auch, dass es nicht oder nur sehr schwer möglich sein wird, eine objektive Instanz zur Bewertung von Einfachheit zu installieren.

    Das ist aber auch gar nicht die Intention des Posts. Ich will niemanden, insbesondere nicht mich und auch keinen Prozess oder ein Richtliniendokument als „Wächter über die Einfachheit“ installieren.

    Die Intention des Posts ist ein Denkanstoß, ein Denkanstoß, der im besten Fall dafür sorgt, dass wir bei unserer Arbeit vielleicht öfter einmal fragen „Was benötige ich (minimal), um die Aufgabenstellung umzusetzen?“ bzw. „Geht es vielleicht noch einfacher?“ anstatt uns zu fragen „Was könnte ich sonst noch machen?“ bzw. „Kann ich noch etwas mehr machen als notwendig?“, eine Fragestellung, die uns heute vielfach treibt, die aber häufig auch zu komplexeren Lösungen als unbedingt notwendig führt.

    Wenn wir bei unserer Arbeit uns stärker von der ersten Fragestellung leiten lassen, uns selber mehr auf das „Notwendige“ als das „Mögliche“ fokussieren, dann erhöhen wir auch die Chance, einfachere und damit leichter wartbare und anpassbare Lösungen zu realisieren.

    Ich ziele also auf die persönliche Einstellung, die persönliche Motivation ab, mit der man an seine Aufgaben herangeht und welche Effekte das haben kann und ich könnte mir vorstellen, dass sich in einem guten Team (egal, ob agil oder nicht) im Laufe der Zeit auch ohne explizite Festlegung ein recht gutes „Bewertungssystem“ ergeben kann, einfach über die gemeinsame Zusammenarbeit und Diskussion, wenn alle Beteiligten sich die Grundidee zu eigen gemacht haben. Das noch als Ausblick auf Deine Fragen, auch wenn das nicht die Zielrichtung des Posts war.

    Gruß, Uwe

Kommentieren

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.