Du bist nicht nett, Flix!

Vor kurzem hatten wir hier auf LinkedIn mal wieder eine interessante Diskussion. Und, wie so oft, ging es dabei natürlich um #Softwarearchitektur. Das tut der Sache aber keinen Abbruch. Lasst mich mal kurz den Kontext für euch abstecken.

In der Softwarearchitektur reden wir oft über sogenannte Microservices. Das sind kleine, relativ autarke Softwaresysteme, die hoch spezialisiert sind und durch die Interaktion miteinander recht komplexe Aufgaben lösen können. Da sie sich in aller Regel, je nach Auslastung, vielfach replizieren können, ist man mit Microservices super aufgestellt, wenn man extrem viele Nutzer und extrem viele Daten hat. Als Videostreaming-Anbieter zum Beispiel. Wie ihr euch aber bestimmt vorstellen könnt, erfordert das Lösen komplexer Aufgaben und schwankenden Bedingungen aber auch einiges an komplexen Herangehensweisen. Die Koordination von diesen Microservices untereinander ist … naja, ihr denkt es euch vielleicht schon, #komplex.

Fehlerbehandlungen, Transaktionen (unter anderem von eurem Geld), Nachverfolgbarkeit, Sicherheit, das sind alles Aspekte, die mit größeren Microservice-Systemen (wir reden hier nicht von 3 oder 4, sondern von ein paar zehntausend laufenden Services) enorm aufwendig umzusetzen sind. Dass der ganze Kram, sogenannte nichtfunktionale Anforderungen, klappt, interessiert den Kunden (und wahrscheinlich auch das ganze Management) zudem auch überhaupt nicht. Zumindest, solange alles gut geht und ihr eure Videos gucken könnt (was eine funktionale Anforderung wäre). Wenn etwas nicht gut geht, dann ist aber schnell die Ka**e am dampfen. Genau deshalb planen wir als Softwarearchitekten nichtfunktionale Anforderungen mit ein, damit wir eine Chance haben, Fehlverhalten von Systemen zu detektieren, zu analysieren und vor allem zu korrigieren.

Aber wie sieht das eigentlich aus, wenn du kein Videostreaming für ein paar dutzend Millionen Kunden machen musst? Oder du jede Stunde einige zig Millionen Pakete über Erdball befördern musst?

Brauchst du dann Microservices? Nein. Wäre die immense zusätzliche Komplexität (und die damit einhergehenden Kosten) irgendwie gerechtfertigt? Ganz bestimmt nicht. Trotzdem neigen Software-Ingenieure dazu, diese architekturellen Ansätze auch auf viel zu kleine Projekte zu übertragen – einfach weil’s cool ist. Oder weil man ja vielleicht irgendwann einmal nicht mehr der Mittelstands-Martin ist, der Lagerverwaltung für Sägewerke macht, sondern der Konzern-Klaus, der Lagerverwaltung für alles und jeden macht. Ein es könnte ja mal rechtfertigt künstlich erhöhte Komplexität aber nicht. Die fachlichen Anforderungen an Software, also dass sie einfach das Richtige tut, sind oft schon komplex genug. Da packt man nicht noch ’ne Schippe drauf.

Geht da ein Licht auf?

Gut. Du merkst es schon, irgendwie gilt das nicht nur für Software. Das gilt, wen wundert’s, für alles. Für die Entwicklung deiner Organisation, für deine Markterschließung, deine Logistik, deine Weiterbildung, deine Personalgewinnung. Ja, vielleicht sogar für deinen Essensplan für die kommende Woche oder die nächste Wandertour.

Flix, ich darf dich doch hoffentlich so nennen?

Du bist nicht nett, wenn du unnötigerweise Komplexität auf Probleme draufpackst, die dort nichts zu suchen hat.

Additive Komplexität ist schädlich. Sie macht nicht nur alles komplexer (das ist offensichtlich, denke ich), sie lenkt zu allem Überfluss auch noch von dem ab, was eigentlich wichtig ist:

Von der Lösung der eigentlichen Herausforderung.

Von dem, was du für dein Umfeld, deine Mitarbeitenden, deine Kund:innen tun kannst. Wenn diese Menschen dir etwas bedeuten, dann löst du ihre Herausforderungen. Und nicht die, die du dir selbst ausgedacht hast.

In der Informatik sagen wir deshalb schon Jahrzehnten scherzhaft:

Every problem can be solved through another level of indirection

Damit wollen wir genau auf diese Unart hinweisen. Die eigentlichen Probleme einfach hinter künstlich geschaffene neue Probleme zu schieben, löst sie nicht. Leider vergessen wir das immer wieder.

Wir sollten das lassen.

Wenn du Lösungskompetenzen hast, dann nutze sie, um die echten Probleme in deinem Feld zu lösen. Arbeite transparent, damit auch andere sehen, dass du auf dem Weg bleibst. Und bleib bescheiden.

Coole Methoden und coole Technologien haben bestimmt ihren Sinn. Aber dort, wo es nur einen Hammer benötigt, sollte es auch der Hammer tun. Denn du bist nicht nett, Flix, wenn du dich nicht an diese Dinge hältst. Mach das gerne dort, wo es um dich geht. Aber nicht dort, wo es um andere geht.