{"id":433,"date":"2009-05-29T10:20:05","date_gmt":"2009-05-29T09:20:05","guid":{"rendered":"http:\/\/blog.adrianlang.de\/?p=433"},"modified":"2009-05-28T21:40:32","modified_gmt":"2009-05-28T20:40:32","slug":"von-der-lust-am-wegwerfen","status":"publish","type":"post","link":"https:\/\/blog.adrianheine.de\/?p=433","title":{"rendered":"Von der Lust am Wegwerfen"},"content":{"rendered":"

Ich habe in letzter Zeit einige Aufs\u00e4tze gelesen, die die Grundlagen der Softwareentwicklung behandeln. Im folgenden m\u00f6chte ich drei der Texte kurz darstellen und bewerten. In diesen Texten geht es grunds\u00e4tzlich darum, was als Ergebnis und Hauptt\u00e4tigkeit der Softwareentwicklung anzusehen ist.<\/p>\n

Es gibt verschiedene Ans\u00e4tze, Softwareentwicklung zu beschreiben. Softwareprozesse gehen h\u00e4ufig davon aus, bis zu einem gewissen Level w\u00fcrde kreativ \u201edesignt\u201c und \u201eentworfen\u201c, danach bzw. darunter nur mehr \u201erealisiert\u201c und \u201ekonstruiert\u201c. Diese Sichtweise wurde bereits 1992 von Jack W. Reeves in \u201eWhat Is Software Design?<\/a>\u201c vehement zur\u00fcckgewiesen. Darin wird behauptet, nur der Quelltext k\u00f6nnte als eigentlicher Entwurf gelten.
\nGleichzeitig r\u00e4umt er ein, dass ein wesentlicher Teil der Softwareentwicklung das Gewinnen eines Verst\u00e4ndnisses f\u00fcr die Problemstellung und den Kontext ist \u2013 Diese Informationen sind jedoch nur selten direkt im Quelltext umgesetzt, sondern bilden die Grundlage des Entwurfs. Reeves fordert folgerichtig, dass diese Informationen in erg\u00e4nzenden Dokumenten festgehalten werden. Er sieht den Grund f\u00fcr diesen Bedarf jedoch haupts\u00e4chlich in der Schw\u00e4che damaliger Programmiersprachen, solche Informationen auszudr\u00fccken.<\/p>\n

Einen grunds\u00e4tzlich anderen Ansatz w\u00e4hlt Peter Naur, der das \u201eTheory building\u201c als hinter der Softwareentwicklung stehendes Konzept sieht<\/a>. Das Erstellen von Dokumenten \u2013 auch Quelltexten \u2013 tritt dabei neben dem Gewinnen eines grundlegenden Verst\u00e4ndnisses f\u00fcr das Problem und dem Entwerfen einer das Programm beschreibenden Theorie zur\u00fcck. Softwareentwicklung wird damit als pers\u00f6nlicher Prozess angesehen, dessen wichtigstes Ergebnis individuelles Wissen der Programmierer ist.
\nZu dieser Erkenntnis kommt Naur durch die Beobachtung, dass bei der Weiterentwicklung von Software ohne Beteiligung der urspr\u00fcnglichen Autoren zentrale Aspekte und Ideen nur selten beibehalten werden k\u00f6nnen. Auf ein Beispiel bezogen behauptet er \u201ethe program text and its documentation has proved insufficient as a carrier of some of the most important design ideas.\u201c<\/p>\n

\u00dcber zehn Jahre sp\u00e4ter betont Joel Spolsky in \u201eThings You Should Never Do, Part I<\/a>\u201c den Wert des Quelltextes und kritisiert die Tendenz, Systeme vollst\u00e4ndig neu zu schreiben, statt das Bestehende zu verbessern. Im direkten Widerspruch zu Naur schreibt er: \u201eWhen you throw away code and start from scratch, you are throwing away [\u2026] knowledge. [\u2026] Years of programming work.\u201c<\/p>\n

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\u00fccken \u2013 Programmiersprachen mit mehr Ausdrucksf\u00e4higkeit, oder Dokumentierwerkzeuge.<\/p>\n

Ich denke, Naurs Konzept hat einen sch\u00e4dlichen Einfluss auf die Softwareentwicklung, denn es best\u00e4rkt die Idee, Neuentwicklungen w\u00e4ren besser als alte Anwendungen. So werden in Quelltext umgesetzte Erfahrungen und realisierte Theorien entwertet.
\nDabei muss klar sein: Jedes real existierende System hat gegen\u00fcber einer Idee den un\u00fcberwindbaren Nachteil des real Existierens. Daraus folgen unangenehme Probleme f\u00fcr 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\u00e4ndlich ist auch der Quelltext nicht so sch\u00f6n wie der gedachte, denn echter Quellcode muss sich mit Bugs, Grenzf\u00e4llen und Kompatibilit\u00e4tsproblemen rumschlagen.<\/p>\n

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 \u00fcberladen und falsch entworfen bezeichnet wird. Und selbstverst\u00e4ndlich ist der Entwurf von Firefox teilweise nicht mehr zeitgem\u00e4\u00df, und der Code teilweise \u00fcberladen; gleichzeitig l\u00e4uft die Software aber gut auf Millionen von Rechnern und scheint f\u00fcr viele Menschen das zu tun, was sie wollen. Es mag sein, dass ein WebKit-basierter Browser irgendwann Firefox verdr\u00e4ngt 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\u00e4ltnis zu diesen Verbesserungen stehen. \u00c4hnliche Entwicklungen sind in vielen anderen Bereichen zu beobachten, wo zyklisch alte Software durch Neuentwicklungen ersetzt wird.<\/p>\n

Es gibt jedoch zwei Punkte, die Spolskys Argumente abschw\u00e4chen: Die soziale Komponente, und die Entwicklung des technischen Umfelds. Gerade freie Software wird oft in einem Gemeinschaftsprozess entwickelt, und dieser Prozess k\u00f6nnte wichtige \u00c4nderungen blockieren. Auch die Verwendung einer neuen Technologie k\u00f6nnte in einem bestehenden Projekt abgelehnt werden. Beide Argumente sprechen aber eher f\u00fcr einen Fork als f\u00fcr eine koomplette Neuentwicklung.<\/p>\n","protected":false},"excerpt":{"rendered":"

Ich habe in letzter Zeit einige Aufs\u00e4tze gelesen, die die Grundlagen der Softwareentwicklung behandeln. Im folgenden m\u00f6chte ich drei der Texte kurz darstellen und bewerten. In diesen Texten geht es grunds\u00e4tzlich darum, was als Ergebnis und Hauptt\u00e4tigkeit der Softwareentwicklung anzusehen ist.<\/p>\n","protected":false},"author":3,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[16],"tags":[303,310,300,308,309,307,304,305,302,160,298,299,306,301],"_links":{"self":[{"href":"https:\/\/blog.adrianheine.de\/index.php?rest_route=\/wp\/v2\/posts\/433"}],"collection":[{"href":"https:\/\/blog.adrianheine.de\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.adrianheine.de\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.adrianheine.de\/index.php?rest_route=\/wp\/v2\/users\/3"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.adrianheine.de\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=433"}],"version-history":[{"count":5,"href":"https:\/\/blog.adrianheine.de\/index.php?rest_route=\/wp\/v2\/posts\/433\/revisions"}],"predecessor-version":[{"id":534,"href":"https:\/\/blog.adrianheine.de\/index.php?rest_route=\/wp\/v2\/posts\/433\/revisions\/534"}],"wp:attachment":[{"href":"https:\/\/blog.adrianheine.de\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=433"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.adrianheine.de\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=433"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.adrianheine.de\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=433"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}