© Stmool/Shutterstock.com
Kolumne: Stropek as a Service

Simplify Your Life: Einfache Lösungen statt künstlicher Komplexität


Ich tüftle gerne an Softwareproblemen. Meine Abende im Advent verbrachte ich mit den Programmierrätseln von Advent of Code [1]. Ich habe großen Spaß daran, für Vorträge, Artikel oder den Unterricht anspruchsvolle Beispiele und Übungen zu erarbeiten. Da darf dann ein Hello-World-Beispiel zu Demonstrationszwecken komplexer werden, als es für die Lösung des vorliegenden Problems eigentlich notwendig wäre.

In meiner beruflichen Arbeit mit Entwicklungsteams mache ich aber gerade im Kontext von Cloud-Anwendungen das genaue Gegenteil: Ich versuche regelmäßig, unnötige Komplexität aus Projekten herauszunehmen. Jedes Projekt hat eine inhärente Komplexität, die sich unvermeidlich aus der Aufgabenstellung ergibt. Vereinfacht man an dieser Stelle, gibt man den Benutzerinnen und Benutzern nicht das, was sie von der jeweiligen Software erwarten. Als Softwareentwicklerinnen und -entwickler fügen wir aber oft selbst Komplexität hinzu, die nicht unmittelbar die funktionalen Anforderungen der Benutzerinnen und Benutzer widerspiegelt. Plausible Gründe dafür sind beispielsweise:

  • automatisierbare Testbarkeit

  • Aufteilung in lose gekoppelte Module, um in mehreren Teams parallel arbeiten zu können

  • Codewiederverwendung über Projekt- und Teamgrenzen hinweg

  • nichtfunktionale Anforderungen, die organisationsweit vorgegeben oder von uns implizit angenommen werden (z. B. Sicherheitsanforderungen, Performanceanforderungen, Industriestandards)

  • Kompatibilität (z. B. Einsatz bestehender Softwaremodule oder Nutzung gewisser Basiskomponenten wie Betriebssysteme, Datenbanksysteme etc.)

Problematisch wird die Sache dann, wenn man es mit dem künstlichen Hinzufügen von Komplexität übertreibt. Ich unterstelle keinem Projektteam, mit dem ich je gearbeitet habe, das in böser Absicht getan zu haben – ganz im Gegenteil! In bester Absicht versucht man, sich an die vielzitierten Best Practices zu halten, von denen man in Vorträgen gehört oder in Büchern und Artikeln gelesen hat. Tut man das, ohne die Hintergründe für diese Empfehlungen zu berücksichtigen, läuft man Gefahr, dass die angeblichen Best Practices das eigene Projekt in den Untergang treiben.

Diese Kolumne ist ein Plädoyer für die Rückkehr zur Einfachheit, für das Verzichten auf überverkomplizierte Softwarearchitekturen, für das Reduzieren auf jene Entwicklungsprinzipien, die für das jeweilige Projekt und Team wirklich notwendig sind.

Microservices

Ich möchte das Thema künstliche Komplexität anhand von Symptomen erläutern, und das erste Symptom ist der übertriebene Einsatz von Microservices. In dieser Kolumne habe ich schon oft über Microservices geschrieben, und die regelmäßigen Leserinnen und Leser wis...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang