Warum Entwickler das Scheitern als Methode begreifen sollten

Hartmut Schlosser

Beim ersten Release ist ein Stück Software selten in einem zufriedenstellenden Zustand. Gründe dafür gibt es viele. Wahrscheinlich kennen Sie alle die Drucksituation, die entsteht, wenn der Kunde/Manager unbedingt zum Zeitpunkt X eine lauffähige Version sehen will.

Man könnte nun stundenlang lamentieren über das mangelnde Verständnis von Außenstehenden, was Software-Entwicklung bedeutet, wie wichtig ausgiebiges Testen für die Qualität ist, dass Funktionalität ohne gutes Layout und gute User Experience nicht zur Geltung kommt.

Oder man kann sich Gedanken darüber machen, wie man solche „unfertigen“ Produkte vermeidet.

Zeit ist knapp – na und?

Nun, der Idealfall wäre natürlich, die Manager geständen die gebührende Zeit und Ressourcen zu, um ein Projekt anständig zu finalisieren. Doch ist die Realität meist eine andere: Zeit ist knapp, Verzögerungen die Regel, scheiternde Projekte kommen erschreckend häufig vor.

Statt nun aber ständig mit Manager/Kunde über Zeitaufschübe und Ressourcen-Aufstockung zu diskutieren, besteht ein relativ neuer Ansatz darin, das Unfertige, Unvollkommene an einer Software von vorne herein als gegeben zu akzeptieren.

Feintuning als Berufsethos

Software wird oft erst dann richtig gut, wenn sie regelmäßig verbessert wird. Es ist bei der Planung und Durchführung eines Projektes also wichtiger, einen langfristigen Maintenance-Modus zu etablieren, als Ressourcen kurzfristig aufzustocken oder gar Überstunden anzuordnen, um zum Zeitpunkt X ein „fertiges Produkt“ abzuliefern. Ohnehin wissen wir alle: Fertig ist eine Software niemals.

Auch Alex Genadinik, Software-Entwickler und Gründer des Startups „Problem IO„, hat Erfahrungen mit solchen „unfertigen Produkten“ gemacht, und mit Projektteams, die nach der Fertigstellung der Grundfunktionalität einfach aufhörten. Wie er auf dem SmartBear-Blog beschreibt, kann man einem Entwickler die „Liebe zum Detail“ auch nur schwer anerziehen. Geht ein Entwickler seinem 8-Stunden-Job nach, indem er seelenlos eine Reihe von Tasks abarbeitet, wird er kaum das Engagement zeigen, das Projekt vom Rohzustand der bloßen Funktionalität weg, hin zu einem erstklassigen Produkt zu entwickeln, das aus der Masse heraussticht.

Selbst als Projekt-Leiter kann Genadinik nicht ständig seine Entwickler antreiben, ihre Arbeit anständig zu machen. Genadinik sagt, dass Erfolg sich erst dann einstelle, wenn Entwickler selbst fasziniert sind von der Projektidee und Eigeninitiative zeigen, die Implementierung ständig zu verbessern. Eine Art Berufsstolz dem Entwickler-Stand gegenüber also.

You really cannot work with people you have to make work. Alex Genadinik

In die selbe Richtung denkt Vinicius Vacanti, CEO von Yipit, der als Programmierlaie für eine Projektidee zunächst ein externes Entwicklerteam engagierte. Nach neun Monaten war der Prototyp immer noch nicht fertig, sodass Vacanti die Dinge selbst in die Hand nahm. Er vertiefte sich in die Programmierung mit HTML/CSS, MySQL, Python/Django, Javascript, AJAX, nginx usw., um nach drei Monaten eine brauchbare erste Version vorzulegen. Ohne Engagement, ohne Faszination, ohne innere Motivation kommt man nicht weit, zieht Vacanti seinen Schluss. Und als persönliche Zwischennote: Wer selbst programmieren lernen möchte, sollte das nicht nur mittels eines Buches oder Programmierkurses machen, sondern anhand eines Projektes, in dem sein ganzes Herzblut steckt.

Scheitern als Methode

Doch zurück zum Problem der unfertigen bzw. fehlerhaften Projekte. Mit unmotivierten Entwicklern ist die nötige Liebe zum Detail nicht zu bekommen – doch ist die Angelegenheit damit sicherlich nicht vollständig erschöpft. Wie bereits beschrieben, ist ein planmäßig eingerichteter Maintenance-Modus wichtig. Weiter gehen Architekturansätze, die von vorneherein so gehalten sind, dass auftretende Probleme schnell isoliert und dann behoben werden können.

Etwa sieht das jüngst veröffentlichte Reactive Manifesto, das im Umkreis der Scala-Entwickler von Typesafe entstanden ist, explizit die Entwicklung robuster („resilient“) Anwendungen vor. Die Möglichkeit von Programmfehlern wird von vorne herein mit in das Programmiermodell hineingedacht.

In a reactive application resilience is not an afterthought but part of the design from the beginning. Making failure a first class construct in the programming model provides the means to react to and manage it, which leads to applications that are highly tolerant to failure by being able to heal and repair themselves at runtime.

Hier dient die Metapher der Schotts eines Schiffes die Vorlage für die Idee, Komponenten-basiert zu entwickeln. Wie die Schotts eines Schiffes verhindern, dass im Unglücksfall der ganze Rumpf des Schiffes vollläuft, so soll sich in der Software-Entwicklung ein Fehler nicht durch die gesamte Architektur ziehen, sondern in klar definierten Einheiten isoliert werden können.

In order to manage failure we need a way to isolate it so it doesn’t spread to other healthy components, and to observe it so it can be managed from a safe point outside of the failed context.

Lose Koppelung und ein Ereignis-getriebener Ansatz wird hier deshalb vorgeschlagen, um dem Ideal der robusten Anwendung näher zu kommen (neben den beiden anderen Werten: skalierbare und interaktive Anwendungen zu bauen).

Fazit

Wenn Ihr Chef Sie wieder einmal antreibt, bis zum nächsten Wochenende die neue Webseite hochzuziehen, machen Sie sich und ihm klar, dass das sicherlich möglich ist, aber nur dann erfolgreich, wenn auch am Montag danach das Feintuning weitergeht. Geht es um größere Projekte, könnte es sich lohnen, sich Gedanken darüber zu machen, durch welchen Architekturansatz sich die Fehleranfälligkeit minimieren lässt. Neu ist das sicherlich nicht: Konzepte der losen Koppelung, der modularen Software-Entwicklung und natürlich auch die Schule des TDD machen schon lange die Runde. In einem neuen Mix präsentiert das Reactive Manifest diese Werte und kombiniert sie mit den Anforderungen moderner Anwendungen, wie heutige User sie erwarten: Ereignis-getrieben, interaktiv und skalierbar. Oder im Reactive-Jargon: „react to events, react to load, react to failure, react to users.“

Geschrieben von
Hartmut Schlosser
Hartmut Schlosser
Hartmut Schlosser ist Redakteur und Online-Koordinator bei Software & Support Media. Seine Spezialgebiete liegen bei Java-Enterprise-Technologien, JavaFX, Eclipse und DevOps. Vor seiner Tätigkeit bei S & S Media studierte er Musik, Informatik, französische Philologie und Ethnologie.
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.