Eine perfekte Software-Lösung wird auf einer schönen grünen Wiese begonnen. Sie ist simple und robust, sie ist aus modernen Komponenten gebaut, nutzt moderne Konzepte und Design-Patterns, ist flexibel und erweiterbar, ist modular und als Fundament für weitere Entwicklungen gedacht. Für Software-Entwickler und Software-Architekten entsteht eine ästhetische Lösung.
Eine perfekte Software-Lösung? Flexibel und erweiterbar und als Fundament für weitere Entwicklungen? Eine schöne grüne Wiese? Höre ich da einen CTO oder Software-Architekten sprechen oder ist es eine naheliegende euphorische Einstellung eines Junior-Entwicklers, der voll Elan die Welt aus den Angeln heben möchte? Eins von beiden muss es wohl sein, denn mit der Realität hat dieser Wunsch nichts zu tun. Zumindest nicht mit der Realität einer Company, die erfolgreich ist oder werden will.
Leider werden solche Ansichten auch bei erfolgreichen Unternehmen geäußert und es wird daher irrigerweise angenommen, dass es eben jene perfekte Lösung war oder ist, die den Erfolg begründet hat. Tatsächlich kommt dies gerade in großen Firmen oft vor und führt zu regelrechten elfenbeinturm-artigen Entwicklungsabteilungen, in der irgendwann mehr die eigene Lösung zelebriert wird, als offen und ergebnisorientiert die Weiterentwicklung voranzutreiben.
Gerade das Thema Erweiterbarkeit löst nach meiner Erfahrung dabei den fatalen Denkprozess aus: es gibt in Wirklichkeit eine Vermutung, eine Annahme, in welche Richtung und auf welche Weise, zukünftige Erweiterungen möglich sein müssen. Unter enormen Aufwand wird die Erweiterbarkeit konzipiert und implementiert, entpuppt sich als Ballast für bisher einfach umzusetzende simple Features und die nötigen Erweiterungen in der Zukunft folgen leider einfach nicht den eigenen Ideen und Vermutungen, die zu diesem neuen Fundament geführt haben. Kurzum, die Erweiterbarkeit erweist sich als unbrauchbar und als verlorene Zeit und Investition. Dieses Scheitern ist oft so schmerzhaft, dass es nicht akzeptiert wird. Es wird die Erweiterung noch ergänzt und ausgebaut. Das Scheitern wird verschleppt und wenn es schließlich eskaliert, war der Grund dafür keinesfalls die Grundarchitektur. Weil nicht sein kann, was nicht sein darf.
In der Praxis habe ich dies auch öfter gepaart gesehen mit dem Drang, immer dem neuesten Hype hinterherzulaufen, ständig die neuesten Entwicklungstools auszuprobieren und irgendwann förmlich „eine Architektur des Selbstzwecks“ zu entwerfen, die an softwaretechnischer Schönheit und Eleganz nicht zu überbieten war, aber leider kein einziges Problem eines Benutzers gelöst hat.
Ich kann diese Lust und Leidenschaft am eigenen Handwerk nachvollziehen. Auch ein Tischler möchte ein in seinen Augen perfekten Tisch zimmern, jeder Installateur hat auch einen eigenen ästhetischen Anspruch und daher eine Vorstellung, wie ein perfektes Badezimmer aussehen sollte. Aber am Ende des Tages löst ein erfolgreiches Produkt ein echtes Problem und kein fiktives. Ein erfolgreiches Projekt setzt einen Wunsch eines Kunden um und nicht des Handwerkers. Eine erfolgreiche Entwicklungsabteilung verlässt bei Bedarf den liebgewonnenen Lösungsraum und diskutiert zusammen konstruktiv die Umsetzung der nächsten Schritte.