Code für alle? Software-Engineering als Muster für den Journalismus der Zukunft

Eigentlich sollten in unserer durch und durch digitalisierten Gesellschaft auch Journalisten mit HTML und Java Script arbeiten können. Aber ist es wirklich notwendig? Der Internet-Pionier und Medien-Unternehmer Christoph Kappes macht sich ein paar grundsätzliche Gedanken über Software-Engineering als Muster für den Journalismus der Zukunft.

*

Datenjournalismus ist eine sehr ansehnliche Sache mit neuen Sichtweisen auf Daten, die sich interaktiv erschließen lassen, die große Datenmengen leichter verständlich macht und bei der man auch über logische und mathematische Operationen neue Daten erzeugen kann. Wer Datenjournalismus nicht kennt, bekommt bei Mirko Lorenz eine brauchbare Einführung und in der Berliner Gazette das Dossier Datenjournalismus zu übergreifenden Fragen.

Spannende Praxisanwendungen finden sich im Data-Journalism-Blog des Guardian. In der New York Times ist jüngst auch ein Überblick über die besten interaktiven Grafiken des Jahres 2012 erschienen, die ähnliche Ergebnisse zeigen. Auch in Deutschland gibt es gute Beispiele: In der Süddeutschen Zeitung etwa gab es ein Beispiel mit Zugverspätungen und ZEIT Online hat Bewegungsdaten veröffentlicht von jemandem, der sich mit seinem Handy bewegt hat und dessen Daten dabei von der sogenannten Vorratsdatenspeicherung erfasst wurden.

Sollen Journalisten künftig diese Art von Journalismus beherrschen, noch weitergehender: sollen Journalisten programmieren können? Meine Meinung: Das kann nicht schaden, aber es muss nicht sein. Wichtiger wäre, die Prinzipien des professionellen Softwareentwicklungsprozesses auf den Journalismus anzuwenden. Doch der Reihe nach.

Zur Programmierung selbst

Programmierung ist ein Handwerk, das sicherlich gut erlernen kann, wer ein Grundverständnis für Analyse, Mathematik und Logik mitbringt. Es zu Erlernen braucht – wie jedes andere Handwerk auch – seine Zeit. (Ich weiß gar nicht, wie viele Jahre ich programmiert habe, es mögen 15 sein; ich würde mich heute immer noch nicht als guten Programmierer bezeichnen.)

Die hohe Dynamik dieses Gebiets sollte nicht darüber hinwegtäuschen, dass viele Grundstrukturen von Dauer sind, also zum Beispiel Rekursion (sich selbst aufrufende Funktionen), Befehlsabfolgen, Schnittstellen (mit denen Programme miteinander kommunizieren) oder Datenstrukturen – auch dort ändert sich nicht so viel, zum Beispiel wie Tabellen funktionieren. Es mag dann ein Jahr oder ein halbes Jahr dauern, bis man da Grundkenntnisse hat und das erste Gefühl dafür entwickelt.

Gegen das Erlernen einer Programmiersprache spricht nichts. Ich denke sogar, dass es heute in die Schulausbildung gehört. Auch in der Journalistenausbildung ist es sinnvoll, Programmieren zu vermitteln. Es ginge dann dort aber nicht nur um das bloße Programmieren, sondern um Informationsverarbeitung im weitesten Sinne. Zum Beispiel darum, wie man auf welche Datenquellen zugreift, wo diese Datenquellen sich befinden, wie der Zugriff rechtlich zu handhaben ist und wie Nutzer-Interaktion konzipiert werden muss.

Es ginge also nicht nur um Datenoperationen, sondern auch um Werkzeuge, Anwendungskonzepte, Interaktionskonzepte und User Experience. Ein weites Feld, für das es in “meiner Internetbranche” schon mehrere Spezialberufe gibt, die mit Massenmedien gar nichts zu tun haben. En passant würde wohl auch besser erlernt werden, wie vielfältig Daten interpretiert und missinterpretiert werden können.

Universalbildung vs. Spezialisierung

Hinzu kommt: Programmierung ist das Paradigma des digitalen Zeitalters. Viele Erscheinungen lassen sich nur vor diesem Hintergrund erklären und verstehen; und zwar nicht nur naheliegende Strukturen von Internet-Informationsökosystemen (Aggregation, Filter usw.), sondern auch weiter entfernte Themen wie Finanztransaktionen, Logistikfortschritt, E-Partizipation.

Datenjournalismus aber ist, genauso wie Bewegtbild-Journalismus und eine Unmenge weiterer Spezialisierungen, eine Unter-Disziplin von Journalismus. Ich glaube nicht, dass diese Spezialisierung jeder können muss, im Hinblick auf das Ergebnis von gutem Journalismus hat Programmierkompetenz unter allen Spezialisierungen keine herausragende Sonderrolle. Aus diesem Grund würde ich es ablehnen, ganz allgemein zu fordern, dass Journalisten programmieren können müssten.

Manche Leute fordern, jeder solle Javascript und HTML können. Das halte ich nicht für zwingend. Es ist in einer modernen Gesellschaft aus meiner Sicht nicht mehr möglich, die Technik, die uns umgibt, im Detail zu verstehen und zu beherrschen, zumal – das vergessen Onlineprofis gerne – auch in anderen Fachgebieten sich Wissen vermehrt, das man eigentlich haben müsste, beispielsweise in Biologie, Chemie, Neurowissenschaften, Psychologie und Soziologie.

Ich würde sogar behaupten, dass jemand, der Menschen und Gesellschaft beobachtet, seine Zeit besser in Psychologie und Soziologie stecken sollte, weil sein Beobachtungsgegenstand nach den Gesetzen dieser Wissenschaften funktioniert und nicht programmierbar ist. Schön ist natürlich, wenn jemand alle Fähigkeiten und Kenntnisse aus Informatik, Politologie und Soziologie mitbringt, gut und verständlich schreiben kann sowie einen guten Riecher für Relevanz und Zusammenhänge hat. Das sollte man jedoch angesichts der typischen Bezahlung nicht erwarten.

Software-Engineering als moderner Prozess der Informationsverarbeitung

Ich glaube, dass hinter der vordergründigen Diskussion vielleicht ganz andere Fragen stecken. Programmierung (oder besser: Software-Engineering insgesamt) ist etwas möglicherweise Modellhaftes für informationsverarbeitende Berufe, weil die Dienstleistungsgesellschaft in ihrer modernen Prägung vor allem eine so genannte „Informationsgesellschaft“ ist und auch Medienberufe im weitesten Sinne zu den informationsverarbeitenden Berufen gehören.

Und weil beim Gegenstand von Medien häufig die Komplexität zunimmt, sind Phänomene im Software-Engineering möglicherweise hoch interessante Hinweise auf Lösungen zur Bewältigung dieser Komplexität:

1. Verteilte Wissensverarbeitungsprozesse entwickeln…

Wir haben in der Softwarebranche fast immer Teams, die eng zusammenarbeiten. Natürlich kann man Programme alleine schreiben und häufig sind Kernteams von Software auch sehr klein. Bei einem Softwarehersteller mit 1.000 Mitarbeitern sind es manchmal keine zehn Core-Entwickler. Aber Software-Engineering ist oft auf verteilte Wissensverarbeitungsprozesse ausgelegt: Teams arbeiten in Gruppen mit bestimmten Rollen zusammen und der Anspruch an die Zusammenarbeit ist sehr hoch, weil die einzelnen Gewerke (Module) nahtlos miteinander zusammenwirken müssen.

In jüngerer Zeit wird auch verteiltes Arbeiten an entfernten Standorten zum Normalfall, wobei auch die Organisation zunehmend loser, entgrenzter wird (vor allem im Offshore- und Nearshore-Bereich). Das Phänomen ist zunehmende Arbeitsteilung bei gleichzeitig stärkerer prozessualer Verzahnung und Steuerung der Einzelschritte.

… um die Qualitätsprobleme der Journalisten zu lösen

Dies weist meines Erachtens für den Journalismus in eine Richtung, um die Qualitätsprobleme zu lösen, die immer mehr wahrzunehmen sind. Vielleicht ist nämlich, was von Journalisten als „Zeitdruck“ und vom Leser als „Schlamperei“ wahrgenommen wird, das Ergebnis gestiegener Anforderungen. Mein Vorschlag ist, beispielsweise Tandems zweier Personen zu bilden oder Arbeitsprozesse mehrstufig anzulegen.

Zum Beispiel (ich kenne das von eigenen Texten zu Internetthemen nur zu gut) kann ein Experte am Anfang einer journalistischen Arbeit Input geben, wie ein Problem angegangen werden könnte, also beispielsweise ein WLAN-Sniff von Google, und auch am Ende könnte vielleicht ein Fachmann nochmal auf das Ergebnis schauen und die Qualität sichern. Es gibt Tausende von Experten, die das aus dem Stand könnten.

In diesem Beispiel mit dem WLAN-Problem hätte jeder Experte sofort erklärt, dass auch eine Google-Software gar nicht anders operieren konnte, als erst alle Daten „abzuhören“ (einschließlich der WLAN-Namen!), bevor sie entscheiden kann, ob sie die Daten speichert.

Auch wir müssen erst die Trillerpfeife hören, bevor wir uns die Ohren zuhalten. Und am Ende hätte vielleicht ein Experte einmal vorrechnen können, wie homöopathisch die E-Mail-Dosis sein muss, wenn man nur Netto-Daten betrachtet, nur Mails und nur die Sekundenbruchteile, in denen sinnhafte Worteinheiten erkennbar waren. Am Ende schaut also ein Fachmann darauf, genauso wie bei Texten über irgendwelche Facebook-Miniaturbilder, was ja im Kern ein juristisches Thema ist. (Bei urheberrechtlichen Fragen wundere ich mich regelmäßig über das eigenartige Selbstverständnis von Journalisten, die über so ein Fachthema schreiben, ohne auch nur über Grundlagenkenntnisse zu verfügen).

Es gibt fast keinen Text auf meinem Fachgebiet, der in technischer, wirtschaftlicher und rechtlicher Hinsicht zugleich fehlerfrei ist – und ich laste das nicht so sehr den Journalisten an, sondern sehe die Ursache im Fachgebiet, das mit common sense nicht mehr durchdrungen werden kann.

Die Lösung ist, arbeitsteilig vorzugehen: Schulterblickverfahren, Pärchenverfahren, gewisse Schrittweise und Prozesse, bei denen man sich näherungsweise an die Lösungen heranarbeitet. Das benötigt natürlich ein bisschen Zeit. Aber auch die Softwarebranche kennt mit „Extreme Programming“ sehr kurze Zyklen und Verfahren, wie man zum Beispiel innerhalb eines Tages zusammenarbeitet. Auch Software entsteht ja häufig unter Zeitdruck.

Ich glaube übrigens auch, dass die Erfahrung von Teamarbeit sehr wichtig ist, damit das schillernd-schrullige Genie ein Korrektiv erfährt. Die tatsächliche Sozialkompetenz so manches Leitkommentators, der Dritte öffentlich herabsetzt (ich denke an Broder vs. Augstein beispielsweise), ist keinen Deut besser als das Zerrbild des bleichen und schüchternen Programmiernerds, der vom Ketchup Flecken auf der Hose hat.

2. Vom Prozess her denken – nicht von den Publikationen

Der zweite Punkt ist, dass man im Software Engineering Arbeitsergebnisse als Prozess versteht. Ich halte es für faszinierend, dass das Nachrichtensystem so Event-getrieben funktioniert und auch heute noch so kurzlebige Ergebnisse produziert, obwohl es vielleicht anders möglich wäre. Hier wird jemand erschossen, da sagt jemand einen Satz, dort lassen sich zwei scheiden – und schon rauscht für 72 Stunden der Blätterwald, um danach nur noch ein Annex-Link zum nächsten Text zu sein, der Ähnliches verhandelt.

Der alte Text wird dann nur an den neuen Text angehängt, meistens um Kontexte wiederherzustellen oder um den Traffic zu erhöhen. Doch dieses Verfahren ist meines Erachtens auf Dauer falsch. Von der Grundidee sind es Themen, die sich gewissermaßen „quer durch die News“ ziehen und die tatsächlich kontinuierlich über drei Monate, drei Jahre oder dreißig Jahre Gültigkeit haben.

Mehr vom Prozess und weniger von der Publikation her zu denken, ist eine Denkweise, die Journalisten helfen würde, nicht mehr so stark getrieben zu sein. Eine Denkweise zudem, die auch dem Publikum helfen würde, nicht ständig von einer Irritation in die nächste zu taumeln – es ist ja eigentlich das Wesen nicht von Wissenserwerb, sondern von Unterhaltung, das psychische System zu irritieren und diese Irritation dann wieder aufzulösen.

Was die Software-Branche hier bietet, ist eine ganz andere Sicht, nämlich Software als Prozess. Software wird natürlich wegen des Ergebnisses für Jahre geschrieben (natürlich hält sie keine zwanzig Jahre). Aber es gibt eben auf dem Weg dahin Methoden, wie man Software in verschiedenen Stages entwickelt, wie man Release-Stände weiterentwickelt, wie man Change-Requests verfasst und wie man das systematisch managet. Es hilft, wenn man einmal diesen Softwareprozess mitbeobachtet hat, um diese Grundstrukturen möglicherweise auch auf journalistische Prozesse zu übersetzen.

Ich glaube, dass dies grundsätzlich die richtige Richtung ist. Für bestimmte Bereiche gibt es natürlich immer Ausnahmen, viele Agenturnachrichten müssen in Windeseile vom Ticker zum Publikum. Für hochwertige Medienmarken wäre es aber die bessere Lösung, dieses Feld den Marktführern zu überlassen. Oder es zu delegieren und ansonsten alle Nachrichten als Micro-Beiträge zu einem größeren Wissensprozess zu begreifen.

So könnte man, wie es beispielweise Wikipedia macht, in Seiten denken, die miteinander verlinkt sind und die in komplexen Strukturen wachsen – mit neuen Zweigen, die weiter sich verzweigen und die aber auch sterbende Zweige haben, die man wieder pflegen muss. Hierzu muss man sich ein paar neue Ansätze ausdenken.

Das wäre gerade für den hochwertigen „Long-Tail-Content“ wichtig, der zwischen 20% und 50% des Inhaltes vieler Nachrichtenangebote ausmacht und den zu verwerten bei allen Nachrichten-Websites Schwierigkeiten macht. Er wird meistens mühselig wieder neu paketiert, als Dossier oder als ausgelagerte Website recycelt. Es wäre ein großer Fortschritt, wenn man diesen wertvollen Inhalt um seine tagesaktuellen Aufhänger gewissermaßen „entmanteln“ könnte, weil dann meistens ein hintergründiges und komplexeres Thema zum Vorschein kommt.

3. Quellen zusammenstellen und verlinken

Mein dritter Punkt ist, dass Software-Ingenieure die sogenannte Runtime (Laufzeitversion von Software) von Quellcode unterscheiden. Die Runtime ist, was im Computer des Benutzers ausgeführt wird; der Quellcode ist etwas anderes, er ist das lesbare Ausgangsmaterial (Informatiker mögen mir diese Beschreibung nachsehen).

Ich denke, da ist eine Parallele zum Quellmaterial und dem Textergebnis des Journalisten. Unter Journalisten ist es bisher nicht sehr üblich, dass man Quellen zusammenstellt und verlinkt (letzteres ein Dauerstreit zwischen Onlinern wie mir und klassischen Journalisten, das möchte ich hier nicht vertiefen). Aber das Verfahren, dass man die Quelle mit dem Arbeitsergebnis „zusammenhält“ und auch immer wieder den Prozess rückwärts vom Arbeitsergebnis auf die Quelle machen kann, wenn man Probleme mit dem Ergebnis hat, das ist eine grundsätzliche Struktur, die vom Software-Engineering abgeguckt werden kann.

Wenn ich als Leser einen Text nicht gut interpretieren kann, möchte ich einen Schritt auf das Quellmaterial zurückgehen können – und diese Option würde, wenn sie denn journalistischer Standard werden würde, auch die Qualität journalistischer Endergebnisse verbessern wie auch den Zwist um Fehlinterpretationen von Quellen verringern.

4. Von der Fehlerkultur von Software-Engineering lernen

Der vierte Punkt betrifft den Umgang mit Fehlern. Jeder Software-Ingenieur sagt ganz entspannt, wach wenn schwere Probleme auftreten, dass „Software Fehler“ habe sei „bekannt“. Es ist ja in der Tat ausführlich erforscht, wie hoch Fehlerquoten bei Software sind. Niemand dort würde sich gekränkt fühlen oder es sonstwie persönlich nehmen, wenn man ihm einen Fehler nachweist; vielmehr ist das gelangweilte Reaktionsmuster meistens: „Ja, bitte trag meinen Fehler ins Bugtrackingsystem ein und dann wird ihn jemand korrigieren.“ Auch gibt es die freudigen Ankläger nicht, die auf Twitter teilweise zu beobachten sind, und die wegen jedes Fehlers mit dem Empörungsfinger auf andere zeigen.

Fehlerkultur ist der vierte Gesichtspunkt, bei dem Journalismus von Software-Engineering lernen kann. Das gilt auch gegenüber dem Publikum, wo der Software-Entwickler seine Nutzer inzwischen regelmäßig zur Kritik einlädt, wer kennt nicht die Feedback-Flyouts am Rande moderner Webseiten (z.B. von UserVoice). Wo sind die Fehler-Flyouts auf Online-Publikationen während der ersten Stunden nach dem Onlinegang?

Und jetzt noch weiterdenken bitte!

Denkt man noch ein wenig länger nach, wird es noch viel mehr Punkte geben. Beispielsweise ist Cross-Plattform-Development möglicherweise ein Muster (pattern) für Cross-Media-Contenterstellung. Und Binnenpluralismus von Medienredaktionen in der Software-Welt einem Multi-Tasking/Threading-System vergleichbar, dessen Tasks/Threads parallel und gleichberechtigt ablaufen.

Wie wäre es, längere Texte als Featureliste vorzuplanen und ganze Artikelstrecken kollaborativ zu planen und zu schreiben? (Auch ich habe mich vor zwei Jahren noch dagegen gewehrt und arbeite heute so mit großer Freude und gutem Ergebnis.)

Ja, vielleicht sind auch manche Debattenthemen wie ein Virus, der von Akteur zu Akteur getragen wird, mit dem wir uns anstecken, der sich von Tag zu Tag modifiziert und der unser Informationsökosystem aus dem Gleichgewicht bringt. Oder ist der Lobbyist ein Virus, der fremde Systemressourcen für den eigenen Zweck nutzt? Brauchten wir den alten Rhythmus der Print-Publikationen zur Denkpause mit “Garbage collection”? Es lohnt sich bestimmt, den Faden noch ein bisschen weiterzuspinnen.

Software-Engineering als Muster für Journalismus der Zukunft by ckappes

Anm. d. Red.: Weitere Beiträge zum Thema in unserem Dossier Datenjournalismus. Die Grafik im Text stammt von Datameer.