Seit vielen Jahren schon arbeite ich als Software-Entwickler. Ich habe Mikrochips programmiert, kleine Windows-Tools geschrieben, Virtual Reality-Umgebungen entwickelt oder CAD-Tools umgesetzt.
Mit dem Schreiben meines Manuskripts begann ich kurz nach dem Start in mein berufliches Leben, und je mehr ich schrieb, desto klarer wurde mir, dass diese zweiten Welten erstaunlich viel gemeinsam haben.
Also fangen wir damit an - den Gemeinsamkeiten.
In der objektorientierten Programmierung dreht sich alles um sogenannte Klassen. Jede davon erfüllt einen bestimmten Zweck, zum Beispiel Benutzereingaben weiterleiten, Daten abrufen oder sich ins Netzwerk einwählen. Ich sehe eine Klasse immer wie eine Szene oder einen Charakter. Eine abgeschlossene Einheit, die mit den anderen in logischer Beziehung steht und in sich schlüssig sein muss.
Damit man Klassen schreiben kann, benötigt man zuerst eine Software-Architektur. Diese gibt den Rahmen vor, welche Klassen überhaupt benötigt werden. Ganz analog benötigt auch ein Roman erst eine Grundstruktur und einen Handlungsbogen, damit die Szenen und Charaktere entwickelt werden können.
Zusätzlich besitzt jeder Roman eine Erzählperspektive. Man könnte auch sagen, dass man damit die User Experience oder das User Interface für sein Buch definiert, denn sie legt fest, "wie" eine Geschichte erlebt wird. In der der Software-Welt nennt man dieses "UI/UX" auch Front End.
Ein Front End gibt es jedoch nicht ohne Back End, also dem Teil der Software, den man nicht direkt sehen kann, wie das Speichern und Laden von Daten. Genauso kann der Protagonist einer Geschichte nur erleben, beschreiben oder erzählen, was ihm die Hintergrundgeschichte ermöglicht - also alles, was im Roman-Universum passiert oder schon geschehen ist.
Die Schreibtechnik ist das Handwerk eines jeden Autors: Wie gute Charaktere, Szenen oder Dialoge geschrieben werden, ist kein Hexenwerk, sondern Übung. Es wurde schon einmal definiert wie das grundsätzlich geht, und daran kann man sich halten. In der Software-Welt nennt man dieses Prinzip Coding Patterns. Für jedes "Problem" gibt es bereits eine oder mehrere geeignete Programmierweisen, die sich bewährt haben.
Aber da ist ja noch der Schreibstil. Jeder Autor schreibt anders, hat seine Eigenheiten und das, was ihn auszeichnet - im Guten wie im Schlechten. Um sich dennoch an allgemeine Lesegewohnheiten zu halten, gibt es so etwas wie "Best Practices". Gilt das nun für den Roman oder Software Code? Ja.
Nachdem ein Stück Software fertiggestellt wurde, geht es häufig ans refactoren. Dabei reinigt man den Code von veralteten Überresten, macht ihn besser lesbar, strukturiert ihn richtig, kürzt überflüssige Funktionen oder teilt zu langen Schlangencode in kleinere Einheiten auf. Wenn man Code durch Text ersetzt, entspricht das 1:1 dem Vorgehen beim Überarbeiten der letzten Szene oder des zuletzt geschrieben Kapitels.
Man muss dabei aber nicht alleine sein. Sobald man selbst einmal drüber gegangen ist, gibt es ja noch Testleser, äh Kollegen, die den Text - ach, ich meine Code - aus ihrer distanzierten Position betrachten und im Code Review Rückmeldungen geben, an welchen Stellen noch Verbesserungsbedarf besteht.
Manchmal kommen beim Testen dann Bugs ans Licht, die gefixt werden müssen. Eine Funktion, die falsche Ergebnisse ausspuckt oder das Programm zum Absturz bringt. Man könnte das auch als Logikfehler (in der Geschichte) oder Ungereimtheiten (bei den Charakter) bezeichnen.
Wichtig ist, dass man sich beim Programmieren an die richtige Syntax der verwendeten Sprache hält - also der Grammatik. Genau wie bei Prosa.
Damit aus meinem Code ein Programm wird, muss er kompiliert, das heißt in Maschinensprache übersetzt werden. Das gleiche geschieht auch bei einem Manuskript, denn genauso, wie ich mir ein fertiges Computerspiel herunterlade und nicht dessen Quellcode, will ich auch nicht die losen Textfetzen sehen, die mein Lieblingsautor in Scrivener zusammengebastelt hat. Ich will das fertig kompilierte, schöne formatierte Buch mit tollem Cover kaufen.
Aber natürlich gibt es auch Unterschiede.
Wobei diese zahlenmäßig deutlich geringer ausfallen.
Da wäre die Linearität. Als Anwender kann ich in einem Programm vor- und zurückspringen, Knöpfe drücken und mal von hier nach da. Als Entwickler kann ich das im Quellcode während der Entwicklung ebenso. Bei einem Roman geht das vielleicht noch der Erstellung oder Überarbeitung - spätestens beim Lesen ergibt eine Geschichte aber nur Sinn, wenn man sie von vorn bis hinten linear konsumiert.
Modularität. Das schöne an (guter!) Software-Entwicklung ist, dass sich Änderungen im Code auf das ganze Programm auswirken. Das Gegenteil davon bezeichnet man als Hard Coded, wenn zum Beispiel bestimmte Variablen fest in den Code hineingeschrieben wurden. Bei einem Roman macht man jedoch genau das - jeder einzelne Satz ist "fest verdrahtet". Wenn zwei Charaktere sich ständig streiten, kann ich das nicht in einzigem Satz ändern und plötzlich ist es eine Romanze. Ich muss das an. jeder. einzelnen. Stelle. anpassen.
Dafür besitzt eine Geschichte einen Spannungsbogen! Ich werde von einer Szene in die nächste gezogen und kann im Idealfall gar nicht mit dem Lesen aufhören. Meinen Quellcode mag ich zwar auch, aber so richtig spannend sind meine geschriebenen Klassen und Funktionen meistens nicht.
Lesbarkeit: Das ist sowohl eine Gemeinsamkeit, als auch Unterschied. Bei Software kommt es darauf an, klar strukturierten Code zu erstellen, den auch später noch jemand verstehen und anpassen kann. Aber das Endprodukt ist die Software, und der Anwender sieht den Quellcode eigentlich nie. Bei einem Buch ist der geschriebene Text gleichzeitig Zwischen-, als auch Endprodukt. Er ist das, was Testleser und Lektoren sehen, ebenso wie der finale Inhalt für den Käufer des Produkts. Die Trennung zwischen Quellcode und Endprodukt existiert nur in geringerem Maße (Stichwort Kompilierung), weshalb die Lesbarkeit hier viel stärker gewichtet ist.
Gibt es noch mehr Unterschiede oder Gemeinsamkeiten? Ja, klar!
Aber das sind die auffälligsten Punkte, die mir immer wieder über den Weg laufen.
Natürlich könnte man diese Auflistung auch auf andere Bereiche übertragen.
Es ließen sich Parallelen zu allen erdenklichen Berufsgruppen finden, denn letztlich entwickelt man als Autor nichts anderes als ein Produkt für einen bestimmten Markt. Es muss Grundanforderungen genügen, um dort überhaupt seinen Platz zu finden, aber auch eine ansprechende User Experience bieten, um die Zielgruppe zu begeistern.
Für mich ist die Tätigkeit in beiden Welten dieselbe. Nur ein paar Feinheiten unterscheiden sich voneinander. In jedem Fall konnte ich aus der einen Erfahrung stets etwas für den anderen Bereich mitnehmen.
Ich hoffe, dieser kleine Exkurs hat euch gefallen. Wenn ihr ähnliche Erfahrungen gemacht habt, freue ich mich, in den Kommentaren davon zu lesen!
Euer Emanuel