Wir sind Software-Gärtner

Selim Baykara

Die Metapher, dass Entwickler eine Art „Software-Gärtner“ seien, hat man inzwischen schon einige Male gehört. Der Gedankengang lautet dabei ungefähr wie folgt: Softwareentwicklung ist kein technisch-mechanisches Abarbeiten von im Vorfeld genau definierten Zielvorgaben, sondern ein organischer Prozess: Man weiß ungefähr, wo man hin will (das Blumenbeet), schmiedet erste Pläne und pflanzt den Samen, aber alle folgenden Schritte sind nicht starr festgelegt, sondern passen sich flexibel an sich ändernde Umstände an.

So weit, so einleuchtend. Als Entwickler stellt sich als nächstes natürlich die Frage: Was bringt mir dieser doch recht vage Vergleich in meiner täglichen Arbeit, und was davon kann ich konkret umsetzen? Genau diese Frage hat auch den Programmierer Nicholas Tuck beschäftigt, der als Anhänger von agilen Entwicklungsmethoden der Gärtner-Metapher naturgemäß nicht abgeneigt ist. In einem Blogbeitrag schaut er sich deshalb genauer an, welche Methoden man anwenden kann, um den Gärtner-Vergleich in der täglichen Programmierpraxis umzusetzen.

Eine bewährte Methode sei beispielsweise das sogenannte „Pair Programming“, bei dem zwei Entwickler Seite an Seite arbeiten. Wie beim Gärtnern funktioniere auch das Programmieren besser im Team – einen Baum pflanze man schließlich auch nicht alleine, und vor allem bei repetitiven Tätigkeiten helfe es ungemein, wenn man sich gegenseitig antreiben könne.

Auch das Aufräumen im Code, das „Refactoring“, ist für Tucks ein zentraler Arbeitsschritt, den sich Softwareentwickler von der Gartenarbeit abschauen können. Wie der Gärtner Unkraut jätet, so muss auch der Entwickler von Zeit zu Zeit den Code säubern und überflüssige Variablen entsorgen, um die Geschwindigkeit und die Funktionalität des Programms zu verbessern.

Pulling weeds is to cleaning up the code. If you don’t technical debt overcomes the garden.

Watering and raking leaves is to improving speed. You don’t have to do either but really should.

Wichtig ist dabei vor allem der Faktor Zeit. Genau wie ein „echter“ Garten benötigt auch ein Softwareprojekt eine gewisse Zeitspanne, in der es zur Reife gelangen kann – dem Projekt einfach mehr Programmierer zuzuweisen funktioniert nicht und ist letzten Endes Geldverschwendung, da „mehr“ nicht zwangsläufig „besser“ heißt.

Das Softwaredesign ist ein weiterer Bereich, der sich für Tucks mit dem Gartenbau überschneidet. Wie ein Gärtner sein Blumenbeet nicht bis aufs letzte Maiglöckchen genau planen könne, seien auch Entwickler in vielen Fällen nicht in der Lage, alle Features eines Programms hundertprozentig im Vorfeld festzulegen.

In software, design often doesn’t go as planned.  This is one of the primary reasons agile practices recommend emergent design. The same has been my experience with gardening.

Gefragt ist eine Form des Designs, bei der die Zielvorgaben nicht starr und unveränderlich festgelegt sind, sondern je nach Situation an geänderte Kundenwünsche, zusätzlich gewonnene Erkenntnisse und neue Arbeitsmethoden angepasst werden können.

Programmierern, die sich für die „Gärtner-Methode“ der Softwareentwicklung interessieren, gibt Tucks zum Schluss noch einen Rat: Ob man sich eher als Entwickler bezeichne oder als Gärtner bleibe jedem selbst überlassen, schließlich könne man sich nennen wie man will. Das klingt zunächst ein wenig unentschieden, ist es aber ganz und gar nicht. Was zählt, ist eben in erster Linie das Ergebnis und nicht, wie man dahin gelangt ist – ganz genau wie in einem echten Garten.

Geschrieben von
Selim Baykara
Selim Baykara
Selim Baykara studiert Anglistik, Amerikanistik und Soziologie an der Johannes-Gutenberg-Universität Mainz.
Kommentare

Schreibe einen Kommentar

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