Viereckige Räder und Miniaturen


I’m constantly surprised when people say, ‘But you haven’t changed!’ It’s like saying, ‘You’ve got a wheel. Now why don’t you make it a square?’

Angus Young

In der Software Entwicklung arbeiten Kreative, Schöpfer, Künstler und Leute, die sich dafür halten.  Tagtäglich werden von ihnen neue Bibliotheken und Frameworks ersonnen um dem User ein paar Probleme zu nehmen und ihn mit einigen neuen Schwierigkeiten zu ärgern.

Viele Anti-Pattern ranken sich um diesen unbedingten Willen des Programmierers, erprobte Frameworks zu ignorieren oder ihnen wenigsten einen eigenen Stempel aufzudrücken. Wie absurd auch immer dieser Stempel konstruiert wurde. Andererseits ist die Grauzone zwischen schlecht nachgemacht und neu erdacht schon recht groß und nicht immer ist es eine dumme Idee, eine eigene Lösung zu erfinden.

Zwei bekannte Anti-Pattern standen Pate für den Titel dieses Beitrags, Reinventing the Square Wheel und Inner-Platform Effect.

Diese beiden hässlichen Schwestern, unterscheiden sich in der Art und Weise, wie sie mit erfolgreichen Lösungen konkurrieren. Die eine versucht eine bekannte Lösung erfolglos zu imitieren und die andere baut, ohne Mehrwert, auf eine bekannte Lösung auf.

Bevor ich ein Beispiel aus der Mottenkiste krame, möchte ich noch versuchen zu erklären, warum schlechte Software überlebt.

Ein paradoxer Nachteil von schlechter Software ist es, dass sie funktioniert. Wir sprechen also nicht von fehlerhaftem Code, sondern von Software, die schlecht strukturiert und kompliziert entworfen wurde, die stark gekoppelt und wartungsintensiv ist. Sie kann relativ lange in der Anwendung arbeiten, bevor sich ihre Nachteile offen bemerkbar machen. Häufig sind die Schwierigkeiten mit dieser Software schon lange innerhalb der Entwicklerteams bekannt.  Häufig ein Hinweis auf organisatorische Defizite, wenn Hinweise nicht zu den Verantwortlichen weitergetragen, oder aber von diesen ignoriert werden. 

Manchmal ist ein Projekt so abhängig von schlechter Software, dass es keinen einfachen Ausweg mehr gibt. Schwierigkeiten manchen dort technische Rahmenbedingungen, die voraussichtlichen Kosten des Umbaus und natürlich die Verantwortlichen, die generell Veränderungen ablehnen oder ihre Kreation schützen möchten, wie Mr. Mushnik seine Pflanze.

In der agilen Software Entwicklung tauchen diese beiden Anti-Pattern relativ selten auf. Die liegt hauptsächlich daran, dass es Diskussionen um die Verwendung von Frameworks gibt und keine einsamen Entscheidungen getroffen werden dürfen. Auch müssen sich  die Lösungen von Sprint zu Sprint beweisen und nicht erst die finale Version funktionieren. Zeigt eine Lösung Schwächen, dann kann von dem Team nachgebessert oder eine Alternative in Betracht gezogen werden.

Vor Jahren durfte ich in ein JSF Projekt einsteigen, bei dem ein Entwickler eine ganz besondere Komponente entwickelt hatte. Mit dieser Komponente konnten Java Beans in einer JSF Seite dargestellt werden. Dieser Entwickler war beim Management hochgeschätzt, seine Konstrukte waren also lange über jede Kritik erhaben.

Angepriesen wurde die Lösung mit dem Argument, dass kein Entwickler versehentlich einen Fehler in eine der  JSF Seiten einfügen könne, weil die Darstellung der Objekte in einer separaten Konfigurationsdatei beschrieben wurde. Diese Datei war in XML geschrieben, wie auch die JSF Seite, und wurde zur Versionierung in einer Datenbank gespeichert.

Leider gab es diverse Schwächen bei dieser Lösung. Bis zum Ende des Projektes konnte nicht auf eine vorherige Version der Konfiguration gewechselt werden. Entweder lud man eine alte Version aus der Datenbank erneut in die Datenbank oder man verwendete einen älteren Stand  der Konfigurationsdatei, wie sie versioniert im SVN des Projektes gespeichert war.

Die Trennung der Daten für die GUI, teilweise im Dateisystem und teilweise in der Datenbank, sorgte mehr als einmal für Verwirrung. Da der Kunde immer wieder neue Ideen für die GUI hatte, mussten die Konfigurationsdatei und die Komponente immer mächtiger werden, bis hin zu einem eigenen Plug-In Mechanismus um Sub-Komponenten einzufügen.

Damit hatte sich diese Komponente zu einer Inner Plattform verwandelt, die JSF imitierte, nur halt sehr schlecht. Das ursprüngliche Verkaufsargument für die Komponente erfüllte sich übrigens auch nicht. Die Konfiguration war noch fehleranfälliger und konnte schlechter getestet werden als die JSF Seiten.

Wer ein Beispiel für Reinventing the Square Wheel sucht, muss nur einmal in eigene Projekten hineinschauen. Vielleicht gibt es dort ein eigenes Logging Framework oder ein Tool zur Dependency Injection oder Internationalisierung? Im oben erwähnten Projekt gab es einen LocalizedString, der anhand eines Schlüssels und einem Locale seinen Inhalt immer in der richtigen Sprache anzeigte. Es gab nichts an dieser Lösung, was nicht auch mit  einem ResourceBundle hätte realisiert werden können, nur war die Verwendung komplizierter und sehr viel unflexibler.

Diese beiden hässlichen Schwestern verschwinden nicht von selber. Sie hocken wie die Harpyien auf dem Quellcode. Wer nicht blind wie Phineus ist, muss nicht auf Rettung warten, sondern kann sie selbst verjagen.