Viel Feind, viel Ehr
Wenn ich einen Kollegen davon erzählen höre, dieses oder jenes sei sehr komplex geworden, dann erwarte ich Bedauern in der Stimme, und keinen Stolz. Leider hab ich immer wieder den Eindruck, dass wir uns mit “Komplexität” den falschen Freund suchen. IT darf sich nicht über die Komplexität ihrer Lösungen definieren.
Ich weiss, für komplexe Probleme gibt es eine einfache Lösung, und die ist meistens falsch. Dennoch: Es gelingt in der Technologie immer wieder, für den Anwender einfache Lösungen herzustellen, auch wenn diesen eine höchst komplexe Entstehung voranging. Nehmen wir mal das iPhone als Beispiel: Smartphones waren vor 2007 nicht besonders smart. Ihre Anwendbarkeit war eingeschränkt, die Benutzung komplex. Apple hat eine einfache Lösung für ein komplexes Problem gefunden, aber… der Weg dahin hat Jahre gedauert und war sicher nicht einfach.
Das ist meine Idee: Ein kundiger Berater kann ein komplexes Problem aus Anwendersicht so gut strukturieren, dass dem Benutzer die Anwendung dadurch einfacher fällt. Mein Elektriker kann einen Schaltschrank für unser Haus bauen, der “nach außen” nur ein paar Schalter und Zähler aufweist, innen aber komplex ist. Komplexität nach Innen kann manchmal unvermeidlich sein.
Im Softwareprojekt ist mein Kollege der Benutzer, oder auch ich selbst als “zukünftiger Verwender”. Die Architektur, die ich entwerfe, die Methode, die ich schreibe, sie stellen das Gesicht meiner Software nach außen dar. Es ist meine Aufgabe als kundiger Berater, möglicherweise nach innen bestehende Komplexität wegzukapseln. Jeder notwendige Handgriff, jede vorausgesetzte Konfiguration ist zu hinterfragen, ob das nicht auch einfacher geht.
Lohn der guten Tat ist ein Softwaresystem, das an seinen Schnittstellen auf geringe Komplexität optimiert ist. Das wird meinem Team, meinem Projekt irgendwann den A**** retten: Unerwartete oder überwältigende Komplexität ist häufig der Grund für Fehler, Verzögerungen und Kostensteigerungen.
Und deshalb sollte es dafür keinen Applaus geben.