Blog

Pragmatismus in der Softwareentwicklung

Softwareentwickler programmieren zusammen

Der Begriff des Pragmatismus, oft missverstanden oder gar missbraucht, fristet viel zu oft ein Schattendasein zwischen angestrebter Perfektion und unnützen Elfenbeintürmen. Dabei können die Prinzipien eines pragmatischen Ansatzes in der Softwareentwicklung viel Positives zu Produktivität, Zufriedenheit und zum Erfolg eines Projektes beisteuern. Ein paar Gedanken zum Pragmatismus in der Softwareentwicklung.

Tun, was getan werden muss

Vielleicht kennen Sie ja das Pareto-Prinzip. Dieses besagt, dass 80 % der Arbeit in 20 % der Gesamtzeit erledigt werden können, während die letzten 20 % der Arbeit 80 % der verfügbaren Zeit in Anspruch nehmen. Ursache dafür ist häufig ein Perfektionismus, der entgegen seinem eigentlichen Anspruch nicht das perfekte Produkt, sondern Ineffizienz und Kostenexplosionen zur Folge hat.

Pragmatiker streben deshalb nicht nach Perfektion, sondern nach Nutzen. Sobald sich dieser Nutzen einstellt, ist dies für den Pragmatiker Beweis genug, dass er seine Arbeit erfolgreich abgeschlossen hat.

Jetzt ist die Frage, wie man diesen Nutzen definiert. Es ist nicht zwingend der Fall, dass darüber immer Einigkeit besteht. So wird der Nutzen häufig aus der Umsetzung einer fachlichen Anforderung extrahiert – aus der Sicht eines Pragmatikers eine absolut eindimensionale und offenkundig falsche Annahme. Menschen, die bei der Beurteilung des Nutzens nur den fachlichen Anforderungen folgen, können nur ein Bild von einer unzureichenden Methode entwickeln.

Ein korrekteres Bild ist das folgende: Ein Softwareentwickler, der den Tugenden des Pragmatismus folgt, wird immer genau so viel Zeit in Design, Tests, Entwicklung oder Dokumentation investieren, wie nötig ist, um den Nutzen der Komponente für alle Stakeholder zu ermöglichen. Dabei liegt die Betonung explizit auf den Wörtern nötig und alle.

Denn sobald der Nutzen einer entstandenen Softwarekomponente vollständig und aus den Perspektiven aller Stakeholder abgeleitet und herausgearbeitet wurde, bedarf es keiner weiteren Schleifen. Es gibt dann schlichtweg keinen Grund mehr für einen erneuten Anstrich, und auch keinen Grund, noch ein Stockwerk draufzusetzen.

Mögliche Stakeholder sind:

  • der Kunde,
  • das Projekt- bzw. Entwicklerteam,
  • der Betrieb bzw. die Administration,
  • die Tester.

Leseempfehlungen zum Thema Softwarequalität: Software Craftsmanship, Clean Code, Refactoring.

Christian Claus

Softwareentwicklung

Enterprise IT-Architekten

Für jeden dieser Stakeholder nimmt der pragmatische Softwareentwickler andere Themen in den Fokus:

    • Der Kunde möchte in der Regel, dass die Arbeit on time, on scope und on budget ausgeführt wird. Dabei hat er vielleicht eigene Qualitätskriterien und einen Releaseplan vor Augen. Eventuell werden auch Kernkomponenten des Projektes von ihm höher priorisiert als andere, um diese einer Gruppe von Betatestern vorzeitig zur Verfügung zu stellen.
      Das Projekt- bzw. Entwicklerteam hat neben der Kundenzufriedenheit vielleicht noch Technologie- und Automatisierungsvorschläge, die es unterbringen möchte.
    • Der Betrieb bzw. die Administration möchte Notfallpläne, Monitoring- und Backupstrategien, und hat gegebenenfalls auch den Wunsch, dass die Applikation am Ende in Form eines Containers ausgerollt wird.
    • Die Tester ihrerseits wünschen sich ein Handbuch, das alle funktionalen Anforderungen des Kunden auf der grafischen Benutzeroberfläche identifiziert und das zu erwartende Resultat beschreibt. Außerdem sollen die Tests möglichst früh und Feature für Feature beginnen. Auch dafür müssen Infrastruktur, Ticketsystem, Ressourcen etc. bereitgestellt werden.
    • Enterprise-IT-Architekten sind ggf. auch mit an Board und beurteilen Design und Architektur der zu entwickelnden Software bereits in der frühen Projektphase oder anhand der zu erstellenden Dokumentation.

All diese und vermutlich noch weitere Stakeholder muss ein pragmatischer Softwareentwickler im Auge behalten. Bei jeder Überlegung und jedem Tastenschlag steht bei ihm der zu schaffende Nutzen für alle Stakeholder im Vordergrund. Dabei ist der Aspekt der Nachhaltigkeit immanent im Begriff des Nutzens verankert.

Aber ein pragmatischer Softwareentwickler wäre kein Pragmatiker, wenn er bei Bedarf keine Ausnahmen zulassen würde. Zum Beispiel kann er von dem Postulat der Nachhaltigkeit abweichen, wenn eine zu entwickelnde Teilkomponente nur einmalig genutzt werden soll, dieses im Vertragswerk fest verankert ist und jene das Versionskontrollsystem nach der einmaligen Nutzung wieder verlässt.

Bei all dem gilt es, die Anforderungen aller Stakeholder nicht stillschweigend hinzunehmen, sondern alles kritisch zu hinterfragen. Können Stakeholder keinen sinnvollen Grund für eine Anforderung anbringen, so ist diese Anforderung vielleicht bereits der Vorbote eines Elfenbeinturms, den zum einen niemand wirklich braucht, da er keinen Nutzen bringt, und dessen Umsetzung zum anderen beachtliche Ressourcen verschwendet. Die Erfahrung hat gezeigt, dass zumeist alle o. g. Stakeholder einem kritischen Diskurs offen gegenüberstehen – sparen sie dadurch doch meistens Zeit und Geld. Ein Pragmatiker agiert indes aber in keiner Weise dogmatisch: Er setzt durchaus auch Lösungen um, die einzelnen Stakeholdern – vielleicht auch ihm selbst – suboptimal erscheinen, sich jedoch als nützlichste Alternative im Gesamtkontext erweisen.

Beispiele für pragmatische Softwareentwicklung



Dokumentation: Dokumentation sollte nach pragmatischen Ansätzen in erster Linie ihren primären Zweck erfüllen. Das bedeutet, dass der Inhalt der Dokumentation genau soviel Informationen über ein Thema in verständlicher Form wiedergeben soll, dass das Zielpublikum den Inhalt versteht. Bestenfalls ist die Dokumentation natürlich in kurzen, prägnanten Sätzen formuliert und mit UML-Notationen versehen. Aber wenn beispielsweise bereits ein verständliches Schaubild zu einer Anforderung existiert, das nicht UML-konform ist, so entwirft der Pragmatiker kein neues UML-konformes, sondern verwendet das vorhandene.

Automatisierung: Wenn ein Entwickler bei wiederkehrenden Aufgaben immer wieder Zeit investieren muss, um gut dokumentierte Schritte händisch abzuarbeiten oder, weitaus schlimmer, bei jedem Build und Deployment nachdenken muss, auf welchen Systemen noch Anpassungen gepflegt werden müssen, damit alles reibungslos funktioniert, handelt es sich offenkundig nicht um ein pragmatisches Softwareentwicklungsteam. Pragmatiker automatisieren nämlich, wo es geht und wo es sinnvoll ist – ob es sich nun um CI/CD handelt, um Serverprovisionierung oder um eine automatisch generierte Chatnachricht des Jenkins Bots, der das Team darüber informiert, dass eine neu eingebundene Bibliothek eine Sicherheitslücke aufweist. Überall, wo Tools und Automatisierung greifen, kann der Entwickler arbeiten und muss sich nicht um das Drumherum kümmern, muss keine Gedanken an Nebenschauplätze verschwenden, sondern kann sich voll und ganz auf das Wesentliche konzentrieren.

Einfachheit strahlt: Es gibt durchaus Entwickler, die Frameworks schreiben, welche nur sie selbst oder einige wenige Spezialisten verstehen. Es gibt außerdem Entwickler, die in kompliziertem Code eine gewisse Ästhetik entdecken. Und es gibt zum Glück pragmatische Entwickler, die wissen, dass unnötig komplizierter Code ihnen selbst und anderen die Arbeit unnötig erschwert. Sie wissen überdies, dass man als Entwickler nicht nur viel Code schreiben, sondern auch viel Code lesen muss und dass die Fehlersuche in komplexen Architekturen nervenaufreibend sein kann. Bei solchen Entwicklern ist vielmehr Orthogonalität gefragt, also die Minimierung von Seiteneffekten und die Reduktion unnötiger Umständlichkeiten. Denn ist Code erst einmal zu einem dichten Spinnennetz gewebt, wird es schwierig, an einer Seite einzugreifen, ohne dass sich das gesamte Netz bewegt.

Pragmatische Softwareentwickler wissen kurz gesagt, dass einfacher Code, klare Architekturen und eine ebenso klare Separation of Concerns große und vor allem nachhaltige Strahlkraft besitzen.

Fazit

Stellt man als Softwareentwickler den Nutzen in den Vordergrund, und zwar den Nutzen für alle Stakeholder, schafft man gute Grundvoraussetzungen, um ein Projekt und dessen Umfeld in eine höchst zufriedene und produktive Umgebung zu verwandeln.