Gefahren des Overengineerings
Ein Produkt ist nur so gut, wie der Kunde es bewertet. Doch die Kunden werden häufig nicht einmal gefragt.
Overengineering ist ein großes Problem bei der Anwendungsentwicklung. Es verursacht Kosten und oft stehen die in keinerlei Verhältnis mit dem angestrebtem Nutzen bzw Mehrwert. Aber wieso kommt es dann vor? Auch Entwicklende haben nur wenig Interesse an aufgebauschten Anwendungen, die nur mit sehr viel Aufwand zu pflegen und zu erweitern sind. Erst recht nicht, wenn man sich erst einarbeiten muss, um auch nur einen einzigen Teil ändern zu können. Die wohl am einfachsten zu verstehenden Ursachen sind falscher Perfektionismus und die Fehleinschätzung der zu produzierenden Anwendung.
Perfektionismus ist so eine Sache. Natürlich will man dem Kunden oder vieleicht nur den eigenen KollegInnen zeigen “Seht her, was ich kann!” und dafür etwas Anerkennung erfahren. Auch der Besteller möchte, dass seine Wünsche respektiert werden. Das ist alles nicht überraschend und meiner Meinung nach auch vollkommen OK.
Als Maurergeselle lernte ich einige Sinnsprüche 1 kennen. Einer davon prägt mein Arbeitsleben bis heute:
Perfektion ist der Maßstab der Nörgler und Inkompetenten. Gut genug ist der Maßstab der Meister!
Als Beispiel möchte ich ein einfaches Suchfeld anführen. Die einfachste Form ist, dass man einen Suchbegriff eingibt und dann eine Ergebnisliste erhält, in dem der Begriff auftaucht. Einige nennen sowas auch “Klartext”-Suche. Der Nachteil ist bspw, dass Schreibfehler zu keinem Ergebnis führen und Synonyme ignoriert werden. Wäre es dann nicht gut, wenn das Suchfeld anhand des Suchbegriffes Vorschläge macht? Suchmaschinen tun das. Und damit die das können, ist unfassbar viel Intelligenz, Forschung und Wissenschaft Voraussetzung gewesen. Und nicht nur das. Ich kann sogar mittracken, was die User gesucht haben, kann Trends in den Suchbegriffen bestimmen und entsprechende Vorschläge machen und damit die Suchergebnisse lenken und Trends bestimmen 2!
Habe ich auf meiner Webseite allerdings eine Galerie mit Pressefotos, wie das Konzerne wie VW oder Siemens unterhalten, ist es meist überhaupt nicht notwendig, eine Vorschlagsliste zu installieren. Und auf meiner Seite brauche ich diese Peripherie erst recht nicht. Aber das stimmt ja nur in dem Kontext, den ich jetzt gerade betrachte. Reicht meine jetzige Implementierung in fünf Jahren noch aus? Gibt es vielleicht ne bessere Lösung, die mit wenig Aufwand einzubinden wäre? Die gibt es sicher. Irgendwo. Aber wie lange will ich da rumsuchen oder ausprobieren? Willkommen im Lösungsgedankenkarusell. Nächste Runde rückwärts, bis jemand kotzt.
Einige leben dann den Grundsatz “Haben ist besser als brauchen” aus und bereiten ihre Systeme von vorneherein mit ensprechenden Frameworks und Bibliotheken vor, um für alle Eventualitäten gerüstet zu sein, obwohl deren Leistungsfähigkeit noch garnicht ausgereizt wird. Und das geht oft nach hinten los.
Stellen Sie sich vor, wie Sie zum TÜV fahren und da kommt heraus, dass ihre Anhängerkupplung, von der Sie dachten, Sie bräuchten sie, Mängel aufweist. Glauben Sie, dass Sie den/die PrüferIn davon überzeugen können, dass Sie die ja nicht benutzen würden und deswegen die Plakette erhalten sollten? Ich auch nicht. So verhält es sich auch bei Anwendungen. Jedes Framework und jede Bibliothek muss aktuell gehalten werden und alle paar Jahre kann es vorkommen, dass neue Versionen nach einem Majorrelease 3 nicht mehr laufen, wie gewohnt. Wenn diese Bereiche dann immer nur so nebenher gelaufen sind, kann das sehr teuer werden oder sogar einen Rewrite 4 erforderlich machen.
Und das ist ja nur der Teil der eingesetzten Frameworks. Über das “Wie” haben wir noch garnicht geprochen. Denn auch da nimmt das Lösungsgedankenkarusell gleich noch mal mächtig Fahrt auf, wenn es darum geht, Oberflächenkomponenten entprechend zu konzipieren und deren Konfigurationsmöglichkeiten zu bestimmen. Nebenbei muss man sich auch die Gedanken über die Datenstrukturen machen, wie man sie erhalten will bzw wegschicken. Als BestellerIn habe ich dabei andere Schwerpunkte: Wie sieht mein ROI aus? Wie kalkuliere ich die Kosten? usw. Und diese auseinanderliegenden Schwerpunkte müssen mit einer guten Entwicklungsprozess verknüpft werden.
Ich kann hier nur an EntwicklerInnen und Bestellende apellieren, sich darüber auszutauschen, was geht und was notwendig ist, bevor auch nur eine Zeile Code in irgendeinem Framework geschrieben wird und sich darauf vorzubereiten, dass es Dinge gibt, mit denen man später besser leben lernt, als ein völlig aufgeblasenes System zu unterhalten, dass am Ende nur einen einzigen Klick spart.
Footnotes
Oder auch “Was man im Dunkeln tut, sieht auch nur im Dunkeln gut aus.” und “Man kann in einer unordentlichen Umgebung keine saubere Arbeit abliefern.”. Vielleicht kennen Sie ähnliche. ↩
Das sind auch die Hauptvorwürfe, die sich Suchmaschinen bzw Firmen wie Google und Microsoft gefallen lassen müssen. ↩
Es gibt da einige prominente Beispiele. Angular und AngularJS bspw. Oder der Versionssprung von 2 auf 3 bei VueJS. Diese Frameworks entwickeln sich weiter, verwerfen alte Fehler und nutzen die aktuellen Fähigkeiten der Browser, die sich genauso fortbewegen. Und das müssen wir auch tun. ↩
Weite Teile der Anwendung sind derart inkompatibel, so dass sie am besten neu geschrieben werden. ↩