Ich habe in letzter Zeit einige Aufsätze gelesen, die die Grundlagen der Softwareentwicklung behandeln. Im folgenden möchte ich drei der Texte kurz darstellen und bewerten. In diesen Texten geht es grundsätzlich darum, was als Ergebnis und Haupttätigkeit der Softwareentwicklung anzusehen ist.
Es gibt verschiedene Ansätze, Softwareentwicklung zu beschreiben. Softwareprozesse gehen häufig davon aus, bis zu einem gewissen Level würde kreativ „designt“ und „entworfen“, danach bzw. darunter nur mehr „realisiert“ und „konstruiert“. Diese Sichtweise wurde bereits 1992 von Jack W. Reeves in „What Is Software Design?“ vehement zurückgewiesen. Darin wird behauptet, nur der Quelltext könnte als eigentlicher Entwurf gelten.
Gleichzeitig räumt er ein, dass ein wesentlicher Teil der Softwareentwicklung das Gewinnen eines Verständnisses für die Problemstellung und den Kontext ist – Diese Informationen sind jedoch nur selten direkt im Quelltext umgesetzt, sondern bilden die Grundlage des Entwurfs. Reeves fordert folgerichtig, dass diese Informationen in ergänzenden Dokumenten festgehalten werden. Er sieht den Grund für diesen Bedarf jedoch hauptsächlich in der Schwäche damaliger Programmiersprachen, solche Informationen auszudrücken.
Einen grundsätzlich anderen Ansatz wählt Peter Naur, der das „Theory building“ als hinter der Softwareentwicklung stehendes Konzept sieht. Das Erstellen von Dokumenten – auch Quelltexten – tritt dabei neben dem Gewinnen eines grundlegenden Verständnisses für das Problem und dem Entwerfen einer das Programm beschreibenden Theorie zurück. Softwareentwicklung wird damit als persönlicher Prozess angesehen, dessen wichtigstes Ergebnis individuelles Wissen der Programmierer ist.
Zu dieser Erkenntnis kommt Naur durch die Beobachtung, dass bei der Weiterentwicklung von Software ohne Beteiligung der ursprünglichen Autoren zentrale Aspekte und Ideen nur selten beibehalten werden können. Auf ein Beispiel bezogen behauptet er „the program text and its documentation has proved insufficient as a carrier of some of the most important design ideas.“
Über zehn Jahre später betont Joel Spolsky in „Things You Should Never Do, Part I“ den Wert des Quelltextes und kritisiert die Tendenz, Systeme vollständig neu zu schreiben, statt das Bestehende zu verbessern. Im direkten Widerspruch zu Naur schreibt er: „When you throw away code and start from scratch, you are throwing away […] knowledge. […] Years of programming work.“
Ich stimme Naur zu, dass das Entwerfen einer Theorie einen wesentlichen Anteil am Programmieren hat. Vorhandenen, getesten Programmcode bewerte ich jedoch ebenso wie Spolsky und Reeves als wichtigstes Ergebnis. Statt diesen zu entwerten, sollten Werkzeuge entwickelt werden, die es leichter machen, die hinter einem Programm stehenden Gedanken auszudrücken – Programmiersprachen mit mehr Ausdrucksfähigkeit, oder Dokumentierwerkzeuge.
Ich denke, Naurs Konzept hat einen schädlichen Einfluss auf die Softwareentwicklung, denn es bestärkt die Idee, Neuentwicklungen wären besser als alte Anwendungen. So werden in Quelltext umgesetzte Erfahrungen und realisierte Theorien entwertet.
Dabei muss klar sein: Jedes real existierende System hat gegenüber einer Idee den unüberwindbaren Nachteil des real Existierens. Daraus folgen unangenehme Probleme für das existierende System: Es zu verstehen und den Quelltext zu lesen ist schwerer, als die eigene Idee zu verstehen, denn Quellcode lesen ist immer schwerer als ihn zu schreiben oder gar nur zu denken; Es hat keine so klare Struktur wie der eigene Entwurf, denn realisiert sehen Strukturen nie so gut aus wie im Kopf. Und selbstverständlich ist auch der Quelltext nicht so schön wie der gedachte, denn echter Quellcode muss sich mit Bugs, Grenzfällen und Kompatibilitätsproblemen rumschlagen.
Und so konnte beobachtet werden, wie aus Netscape 4 nach komplettem Neuschreiben Netscape 6 wurde, aus welchem bis heute Firefox 3 entstand; jenes Firefox, welches heute von vielen als überladen und falsch entworfen bezeichnet wird. Und selbstverständlich ist der Entwurf von Firefox teilweise nicht mehr zeitgemäß, und der Code teilweise überladen; gleichzeitig läuft die Software aber gut auf Millionen von Rechnern und scheint für viele Menschen das zu tun, was sie wollen. Es mag sein, dass ein WebKit-basierter Browser irgendwann Firefox verdrängt hat, und wahrscheinlich wird er auch deutlich besser als Firefox sein. Der Aufwand und die Menge an doppelt gemachten Fehlern wird jedoch in keinem Verhältnis zu diesen Verbesserungen stehen. Ähnliche Entwicklungen sind in vielen anderen Bereichen zu beobachten, wo zyklisch alte Software durch Neuentwicklungen ersetzt wird.
Es gibt jedoch zwei Punkte, die Spolskys Argumente abschwächen: Die soziale Komponente, und die Entwicklung des technischen Umfelds. Gerade freie Software wird oft in einem Gemeinschaftsprozess entwickelt, und dieser Prozess könnte wichtige Änderungen blockieren. Auch die Verwendung einer neuen Technologie könnte in einem bestehenden Projekt abgelehnt werden. Beide Argumente sprechen aber eher für einen Fork als für eine koomplette Neuentwicklung.