Meinung: Softwareentwicklung ist keine Kunst

Inhaltsverzeichnis

Ich gebe zu, dass ich ein großer Fanboy bin – und zwar von dem US-amerikanischen Informatiker Donald E. Knuth. Er wurde bereits 1938 geboren und arbeitet seit Jahrzehnten an einem der, wenn nicht gar an dem größten literarischen Werk der Informatik schlechthin, nämlich: "The Art of Computer Programming". Vielleicht kennen Sie ihn aber auch aufgrund eines der zahlreichen Zitate, die auf ihn zurückgehen, beispielsweise:

„Hüten Sie sich vor Fehlern in oben stehendem Code. Ich habe nur bewiesen, dass er korrekt ist, aber ich habe ihn nicht getestet.“

Solche Sätze, die zugleich lustig, tiefgründig und intelligent sind, gibt es einige von ihm. Eine Frage, mit der er sich dabei intensiv und immer wieder beschäftigt, lautet: Was zeichnet Softwareentwicklung eigentlich letztlich aus? Handelt es sich um eine Kunst oder eher um eine Ingenieurswissenschaft?

the next big thing – Golo Roden

Golo Roden ist Gründer und CTO von the native web GmbH. Er beschäftigt sich mit der Konzeption und Entwicklung von Web- und Cloud-Anwendungen sowie -APIs, mit einem Schwerpunkt auf Event-getriebenen und Service-basierten verteilten Architekturen. Sein Leitsatz lautet, dass Softwareentwicklung kein Selbstzweck ist, sondern immer einer zugrundeliegenden Fachlichkeit folgen muss.

Code vor dem Kamin lesen

Ein Zitat von Donald E. Knuth habe ich gerade bereits erwähnt, aber es gibt noch ein anderes, das für mich persönlich das mit Abstand schönste ist, nämlich:

"Wann haben Sie es sich das letzte Mal vor dem Kamin gemütlich gemacht und ein gutes Stück Code gelesen?"

Ich vermute, dass Sie das wahrscheinlich noch nie gemacht haben – ja, dass Sie wahrscheinlich noch nicht einmal jemals darüber nachgedacht haben, dass man das eigentlich einmal machen könnte. Da stellt sich doch die Frage: Wo wir als Entwicklerinnen und Entwickler jeden Tag von morgens bis abends mit Code hantieren, wo Code für viele von uns eine Sprache wie Englisch oder Französisch ist, und wo wir dermaßen viel Zeit damit verbringen, Code zu schreiben, warum nehmen wir uns nicht die Zeit, ihn mit der angemessenen Aufmerksamkeit und wohlwollender Wertschätzung zu lesen?

Und zugegeben: Es klingt zunächst reichlich seltsam, das zu machen. Aber, wenn Sie Informatik studiert haben, dann werden Sie sich vielleicht daran erinnern, dass im Studium immer wieder einmal die Rede davon war, man solle nach eleganten und schönen Lösungen suchen. Und das kennen wir auch aus anderen wissenschaftlichen Disziplinen, wie zum Beispiel der Mathematik: Auch dort ist immer wieder von schönen und eleganten Beweisen die Rede. Wenn also Algorithmen oder Beweisen eine Ästhetik innewohnt, warum nehmen wir uns dann nicht die Zeit, sie einmal ganz bewusst wahrzunehmen und sie gegebenenfalls auch, wenn sie besonders gelungen sind, entsprechend zu bewundern?

Code als Kunst?

Vielleicht sagen Sie nun, dass Ihnen das zu akademisch und zu abgehoben ist, aber denken Sie doch einmal kurz über das Wort "Hacker" nach. Heute bezeichnen wir damit jemanden, der mit bösen Absichten in Computer einbricht und Daten stiehlt oder zerstört. Ein Hacker ist heute ein Vandale, ein Verbrecher. Aber das war nicht immer so. Als das Wort in den 1980er- und frühen 1990er-Jahren aufkam, bezeichnete es jemanden, die oder der komplizierte und komplexe Probleme auf intelligente, schlaue und einfache Art lösen und elegante und schöne Lösungen in Code zaubern konnte. Mit anderen Worten: Es gab eine Zeit, in der wir Ehrfurcht vor Codekünstlern hatten.

Empfohlener redaktioneller Inhalt

Mit Ihrer Zustimmmung wird hier ein externes YouTube-Video (Google Ireland Limited) geladen.

YouTube-Video immer laden YouTube-Video jetzt laden

Ich bin damit einverstanden, dass mir externe Inhalte angezeigt werden. Damit können personenbezogene Daten an Drittplattformen (Google Ireland Limited) übermittelt werden. Mehr dazu in unserer Datenschutzerklärung.

Und wenn man sich noch einmal den Titel des monumentalen Werks von Knuth vor Augen führt, dann fällt auf: Es heißt "The Art of Computer Programming", nicht einfach nur "Computer Programming" oder ähnlich. Es geht um "the art", also um die Kunst der Programmierung. Und Knuth will das auch tatsächlich genau so verstanden wissen, denn er hat Programmieren verschiedentlich zum Beispiel mit dem Komponieren von Musik oder dem Dichten verglichen, dass das alles ästhetische Erfahrungen seien, bei denen Schönheit geschaffen werde. Ich persönlich empfinde es als bemerkenswert, einmal aus dieser Perspektive über das Schreiben von Code nachzudenken.

Softwareentwicklung als Ingenieurswissenschaft

Wenn wir das nun einmal damit vergleichen, was im Alltag und im Job der meisten Entwicklerinnen und Entwickler passiert, dann ist das üblicherweise weit von Kunst entfernt. Das merkt man unter anderem sehr rasch an den Begriffen, mit denen wir uns umgeben: Da geht es um Software-Engineering, da geht es um Software-Factories, da wird Informatik als Ingenieurswissenschaft gesehen, die vorhersagbar, planbar und deterministisch sein soll. Mit anderen Worten: Das ist dermaßen weit weg von einer künstlerischkreativen Sichtweise, dass es schon erstaunlich (oder, je nach Sichtweise, erschreckend) ist.

Ganz automatisch stellt sich dann die Frage: Wer hat denn nun recht? Was ist Informatik denn eigentlich tatsächlich? Was ist das Wesen und was ist der Kern des Ganzen?

Ein Blick in die Industrie zeigt, wohin die Reise geht: Tests? Werden oft weggelassen, kosten unnötig Geld und sind nicht so wichtig. Man weiß ja: Man bekommt günstigere Software durch weniger Tests. Dokumentation? Auch die braucht nicht unbedingt jemand, auch sie kostet nur Geld und vor allem Zeit. Clean Code? Naja, wenn es unbedingt sein muss, dann können wir vielleicht einmal eine Woche einen Refactoring-Sprint machen, aber danach muss man dann bitte wieder neue Features schreiben, denn der Kunde zahlt schließlich nicht für Clean Code. Der Kunde zahlt nämlich generell nicht für den Code, der ist ihm nämlich komplett egal. In Wahrheit zahlt der Kunde stattdessen dafür, dass wir ein Problem pragmatisch und effizient lösen. Und dass wir das mit Code und nicht mit einem Schraubenzieher machen, ist dabei bestenfalls ein drittrangiger Seitenaspekt.

70.000 Zeilen PHP-Code

Das Erstaunliche an alldem ist, dass es funktioniert. Ich habe vor etlichen Jahren jemanden in einem großen Konzern kennengelernt, der alleine an einer Analyse-Software für den Vorstand gearbeitet hat. Sein Code (und diese Geschichte ist tatsächlich wahr und kein Scherz) bestand aus 70.000 Zeilen PHP-Code in einer einzigen (!) Datei. Es gab keinen einzigen automatisierten Test, kein automatisiertes Deployment, keine CI/CD-Pipeline oder Ähnliches. Er hat nicht einmal mit einer Versionsverwaltung gearbeitet, sondern mit VI direkt die eine einzige PHP-Datei auf dem Produktivserver editiert.

Und tatsächlich fand er das gut so, denn: Wenn er diese eine Datei dann nach Stunden des Editierens endlich gespeichert hat, war die Anwendung sofort neu deployed. Das Schlimmste daran war, dass er in dem Team, zu dem er gehörte, derjenige war, der die mit Abstand stabilste und verlässlichste Software geschrieben hat. Das Sahnehäubchen an alldem: Das PHP-Skript war über mehrere Symlinks erreichbar, und je nachdem, wie es aufgerufen wurde, hat es sich anders verhalten. Der Vorstand hat ihn geliebt, aber alle anderen im Team haben ihn verflucht und jedes Mal gezittert, wenn er in den Urlaub gegangen ist oder krank war.

Woher die Diskrepanz?

Als externer Berater, als der ich damals für dieses Team fungiert habe, steht man dann da, mit all den Best Practices, die man für gute Codequalität vermitteln möchte, wie Unit-Tests, Integration-Tests, statischer Code-Analyse, Versionsverwaltung, Containerisierung, Continuous-Integration, Continuous-Deployment und so weiter, und es wird einem gesagt, das sei ja alles schön und gut, aber es würde alles hervorragend funktionieren, und es bringe nur Unruhe hinein, am bestehenden Vorgehen etwas zu ändern.

Und so sehr mich diese Sichtweise aus der einen Perspektive ärgert, muss ich auf der anderen Seite doch zugeben: Ja, er hat mit seinen 70.000 Zeilen PHP-Code auf dem Produktiv-Server das zugrunde liegende Problem gelöst und dem Vorstand verlässlich und termingerecht die gewünschten Zahlen geliefert. Das war das, was (zumindest aus einer gewissen Perspektive) wichtig war. Dennoch habe ich noch nie, wenn ich diese Geschichte erzähle, jemanden getroffen (und zwar völlig egal ob Entwickler oder Managerin), die oder der gesagt hätte: "Wow, super! So machen wir das ab sofort auch!"

Denn irgendwie wollen dann am Ende doch alle mehr Verlässlichkeit im Hinblick auf Qualität & Co. haben, zumal das auch das ist, was auf jeder Konferenz, auf jedem Meetup, in jedem Blog oder auf YouTube erzählt wird, unter anderem auch von Leuten wie mir. Aber auch ich muss zugeben, dass der Pragmatismus und die rein auf das Lösen des Problems ausgerichtete Entwicklung nicht von der Hand zu weisen ist. Es ist effizient. Aber warum empfiehlt das trotzdem niemand? Woher kommt diese Diskrepanz?

Kunst versus Business

Letztlich glaube ich, dass das daher kommt, dass hier zwei gegensätzliche Sichtweisen aufeinanderprallen: Hier trifft nämlich Kunst auf Business. Und Informatik ist am Ende beides zugleich, Informatik ist eine Dualität. Die Auswirkungen dieser Dualität erleben wir im Alltag ständig, denn es gibt tagtäglich Reibungspunkte, wo diese beiden Welten und diese beiden Perspektiven in Konflikt miteinander geraten. Das fängt schon damit an, wenn man eine Aufwandsschätzung abliefern soll. Ich persönlich denke mir da immer: "Was weiß denn ich, wie lange ich für XY brauchen werde?"

Es heißt schließlich Softwareentwicklung und nicht Softwareproduktion, und ich könnte den Aufwand genau dann vorhersagen, wenn ich die Aufgabe vorher schon einmal so oder zumindest so ähnlich bewerkstelligt hätte, aber dann könnte ich den Code von der vorherigen Implementierung auch einfach kopieren und müsste ihn nicht neu entwickeln. Und das geht nicht nur mir so, das geht ganz vielen Entwicklerinnen und Entwicklern so, weshalb ich persönlich das Schätzen von Aufwand für relativ sinnfrei halte.

Denn letztlich ist es, wenn man eine Entwicklerin oder einen Entwickler nach einer Aufwandsschätzung fragt, wie wenn man Picasso fragen würde, ob er bitte mal schätzen könne, wie lange er für das Bild von einem Krokodil brauchen würde, immerhin sei das von seinem Dackel ja auch nur ein einziger Strich gewesen und könne höchstens fünf Minuten gedauert haben. Die Wahrheit ist aber: Kunst lässt sich nicht schätzen. Umgekehrt kann ich aber auch verstehen, dass man im Business planen können und Ergebnisse sehen möchte: Wenn ich ein Haus baue, will ich auch nicht hören, dass der Rauputz noch nicht fertig ist, weil "die Hand des Maestros seit einer Woche nicht den richtigen Schwung und die richtige Eingebung finde, um die Kelle zu führen".

Es braucht eine Skala

Allerdings sind diese beiden Sichtweisen zugleich auch die beiden Extreme, und wie immer, wenn es zwei Extreme gibt, gibt es auch etwas zwischen den Polen. Das heißt, am Ende sprechen wir bei der ganzen Angelegenheit über eine Skala. An deren einem Ende steht die reine Kunst, die Software und Code als Selbstzweck ansieht, quasi "l’art pour l’art". Am anderen Ende der Skala steht das rein pragmatische Business, wo es nur darum geht, Probleme möglichst effizient und kostengünstig zu lösen und sich (Achtung, Wortwitz) nicht zu verkünsteln. Code und Software sind hier ein reines Mittel zum Zweck.

Die Wahrheit liegt, vermute ich, irgendwo dazwischen, denn Kunst ohne Anwendung kommt nicht aus ihrem Elfenbeinturm heraus. Aber Anwendung ohne Kunst hat keine Seele. Und die alles entscheidende Frage lautet: Wo stehen Sie auf dieser Skala?

Ich glaube, wenn sich mehr Entwicklerinnen und Entwickler über diese Frage Gedanken machen und für sich einen Standpunkt definieren würden, und wenn Unternehmen dasselbe tun würden, und wenn man dann über das jeweilige Wertesystem sprechen würde, dann würde Entwicklung deutlich besser und reibungsloser verlaufen, weil es weniger Konflikte und Missverständnisse über die Natur der Entwicklung an sich gäbe.

Und dann wäre Softwareentwicklung am Ende vielleicht tatsächlich genau das: keine Kunst. (rme)