Mittwoch, 23. Februar 2011

Gute Software braucht Ausdauer

In meinen letzten Postings ging es um die Freiheit und die Kunst des (Software-)Hackers. Heute geht es um die ehr unerfreulichere Seite: Die Ausdauer während der Entwicklung.

(Date/Datum: 080322-17:59, Hits: 1931)

Bei der Eigenentwicklung von OpenSource-Projekten fiel mir immer wieder auf, dass diese Projekte speziell zu Entwicklungsanfang einen großen Spaßfaktor mit sich brachten. Man plant die Software und ihre Bestandteile und macht es ganz nach Lust und Laune mit oder ohne (in meinem Fall: fast komplett ohne) erlernte Entwicklungsmodelle, UML-Diagramme, Bildchen usw., einen ersten, (zweiten, (dritten, ...)) Entwurf des tollen neuen Projekts.

Der nächste Schritt besteht oft darin, die besonders interessanten Komponenten zu programmieren (das erinnert mich an einen Satz, den ich während des Studiums "lernen" durfte, und den ich nie vergessen und schon gar nicht in mein Denken übernehmen werde: "Das Programmieren ist der stupide Teil der Softwareentwicklung." -- soetwas sagen nur Menschen, die meinen, Software-Architekten seien über die lausigen Entwickler erhaben ...). Nachdem dann alle besonders interessanten Komponenten implementiert wurden, kommen die aufgeschobenen, langweiligen Arbeitsschritte auf einen zu. Und genau hier liegt der Grund, warum viele OpenSource-Projekte scheitern: Die Entwickler verlieren das Interesse! Im kommerziellen Umfeld kann der Vorgesetzte an diesem Punkt eventuell durchgreifen und die Entwicklung vorwärtstreiben (das muss er sogar können!), doch in OpenSource-Projekten gibt es eine solche Antreiber-Person oft gar nicht. Trotzdem gibt es unzählige Vorzeige-Projekte, die von OpenSource-Entwicklern erstellt wurden.

Dem Entwickler bieten sich dann mehrere Möglichkeiten an:

Möglichkeit 1: Er veröffentlicht ein "unvollständiges" Projekt als "Spezialprojekt" (so, wie ich es beispielsweise mit meinem XyriaDNSd getan habe (und diese Software als Extreme-Performance-Server hingestellt habe), weil ich zu faul war das gesamte DNS-Protokoll RFC-konform zu implementieren). Im Übrigen ist dieser DNS-Server mindestens einer der schnellsten der Welt, vielleicht sogar der schnellste!

Möglichkeit 2: Er macht es sich noch einfacher und bricht das Projekt ab.

Möglichkeit 3: Er beißt in den sauren Apfel und zwingt sich dazu, das Projekt weiter zu entwickeln. In diesem Fall tut er nicht das, was er eigentlich tun will und -- für den Fall, dass er seine Tätigkeit so, wie ich, als Kunst ansieht -- wird er sich die Frage stellen, ob er damit nicht seine künstlerische Freiheit in gewisser Weise einschränkt und ob das gut für ihn ist.

Möglichkeit 4: Er übergibt das Projekt einem anderen Projektleiter, den er zunächst suchen und begeistern muss (bei kleinen Projekten oft kaum möglich). Fündig werden könnte der Entwickler beispielsweise beim SourceForge.net-Jobforum. Dort muss er aber nicht nur einen oder mehrere Entwickler finden, sondern auch fähige.

Möglichkeit 5: Er sucht sich Entwickler, die für ihn die Implementierung vollenden. Hier gibt es ähnliche Probleme, wie bei Möglichkeit #4.

Nach längeren Überlegungen und der Betrachtung meiner bisherigen Halbfertig-Projekte bin ich zum Schluss gekommen, dass eine gewisse Ausdauer wohl doch von Nöten ist, um ein gutes Ziel zu erreichen. Aber nur manchmal. Weniger ein sich-zwingen als vielmehr ein sich-motivieren scheint der gesunde und richtige Schlüssel dazu zu sein.

Der Grund dafür ist der übliche: Guter Code und gute Kunst braucht Begeisterung!

Vielleicht könnte man also sagen, dass es -- analog zur ausgewogenen Ernährung, bei der leider nicht alles toll schmeckt -- eine ausgewogene OpenSource-Entwicklung benötigt, bei der Begeisterung und Ausdauer zwei Kernbestandteile sind.

Keine Kommentare:

Kommentar veröffentlichen