Kann die Wissenschaft von der Praxis lernen?

Wenn ich diese Frage stelle, wissen die Kollegen, die mich kennen, bereits, worauf ich hinaus will. Vielleicht sollten sie dennoch etwas Geduld haben. Es könnte ja sein, dass ich Dinge sagen werde, die sie so noch nicht gehört hatten.

Wieso kann etwas überhaupt als Wissenschaft gelten, wenn es auf die Praxis angewiesen ist, um zu lernen? So werden vermutlich einige Leser fragen. Wenn sie aus der Informatik kommen, ist das nicht einmal verwunderlich. Die mathematische Erblast macht sich hier noch bemerkbar. Es gibt zweifellos einige Wissenschaften, für die Praxis-Feedback keine Bedeutung hat. Das liegt vielleicht sogar in ihrer Natur. Warum auch diese Wissenschaften – ich nenne bewusst keine Beispiele – trotzdem mit Steuermitteln unterstützt werden müssen, ist eine andere Diskussion. Beispiele im positiven Sinne sind neben der Medizin alle Ingenieurwissenschaften. Sie sind ohne Zweifel förderungswürdig. Es sind dies in Hartmut Wedekinds Worten halt Notwissenschaften, keine freien Wissenschaften.

Wenn wir die im Titel gestellte Frage bejahen, muss man  fragen, was und wie man lernen kann. Ich gebe nur ein paar Stichworte, zunächst zum ersten Themenkreis.

Es ist wichtig zu wissen, was echte Probleme sind. Für die Lehre mögen erdachte Probleme ausreichen. Wenn dies für die Forschung auch geschieht, ist dies zweifellos ein Mangel. Weiterhin ist es wichtig zu wissen, welche Lösungen und Verfahren funktionieren, und zwar wo und wann? Welche Kosten und Nebenwirkungen haben sie? Welche relative Bedeutung haben gewisse Anwendungen und deren Probleme, usw.

Viel schwieriger ist die Frage zu beantworten, wie die Wissenschaft von der Praxis lernen kann. Es ist eine Illusion zu glauben, dass Praktiker in Fachzeitschriften und auf Fachtagungen in genügendem Maße berichten werden. Das A und O ist, dass Wissenschaftler sich selbst darum bemühen, Projekte der Praxis zu verfolgen und auszuwerten. Je größer die Projekte sind, umso mehr lässt sich lernen. Erfolgreiche Projekte sollten dabei an erster Stelle stehen. Es ist psychologisch einfacher Menschen über ihre Erfolge reden zu lassen als über ihre Misserfolge. Zuerst sollte man wissen, was funktioniert. Das sollte an andere Fachleute übertragen und von ihnen nachgeahmt werden. Aber auch aus fehlgeschlagenen Projekten kann man lernen. Manche Leute meinen, dass man daraus sogar mehr lernen könnte als aus erfolgreichen. Es ist aber erheblich schwieriger. Im Endres/Gunzenhäuser (2010) heißt es (auf Seite 24): 
 

Fehlgeschlagene Projekte zu analysieren, ist andererseits eine unbeliebte Tätigkeit. In Deutschland erfolgen solche Analysen noch eher zufällig. Wenn dies dennoch geschieht, behalten die Betroffenen die daraus gewonnenen Lehren am liebsten für sich. Für die Informatik wäre es aber besser, wenn bei jedem großen Projekt zusätzlich eine wissenschaftlich geleitete Analyse stattfinden würde. Dies wäre eine lohnende Aufgabe für Hochschulen, die das so gewonnene Wissen an spätere Generationen von Informatikern weitergeben könnten. Eine positive Ausnahme in dieser Hinsicht ist Peter Mertens (2009). Er hat einige bekannte Projekte aus dem öffentlichen Bereich analysiert, darunter das größte europäische Informatikprojekt der letzten Jahre, die Erfassung der Lkw-Maut auf den deutschen Autobahnen durch die Firma Toll Control.

Im Jahre 2012 hat Mertens [2] diese löbliche Arbeit fortgesetzt und vertieft. Durch die Wiederholung des Themas betont Peter Mertens, wie sehr ihm dieses Anliegen am Herzen liegt. Im Gegensatz zu andern Kollegen begnügt er sich nicht mit akademischer Selbstbefriedigung. Für meine Begriffe beschränkt er sich aber sehr in seinen Aussagen, und zwar auf die betriebswirtschaftlich relevanten Aspekte. Eine vollständige Projektauswertung sollte alle Aspekte des Projekt-Management und des Technologie-Managements erfassen. Dazu gehören außer Kosten und Terminen auch angestrebte und erzielte Qualität und Produktivität, benutzte Methoden und Werkzeuge, nachgewiesene Benutzerfreundlichkeit und Sicherheit. Außerdem ist es notwendig, dass nicht nur einer sondern alle Hochschulkollegen in diese Richtung denken.

Die Praxis hat es ihrerseits schwer, wenn sie von der Wissenschaft nicht beachtet wird. Praktiker haben in der Regel nicht die Zeit, um zu reflektieren oder um an Übermorgen zu denken. Theoretiker müssen Theorien bilden. Sie müssen das Warum ergründen, und zwar in allen Dimensionen. Das ist wichtiger als die Beschreibung von Problemen oder Methoden zu verschönern. Leider haben viele der akademisch ausgebildeten Informatiker nur das Formalisieren oder Mathematisieren gelernt, nicht jedoch das Bilden von Theorien. Auch Erfinden wird noch nirgends gelehrt, so als ob wir es nicht nötig hätten. Schon wieder sind wir bei den Notwissenschaften gelandet!

Nur in der Frühzeit der Informatik bauten Akademiker Rechner oder Compiler selbst. Sie haben es für sich selbst getan. Die damaligen Erfolge und Erfahrungen flossen als Erklärbares (also Theorien) direkt in Lehrbücher und wurden als Wissen an Studenten transferiert. Der Stoff, der aus eigenen Projekten stammte, wurde verarbeitet und verallgemeinert. Allmählich ersetzte dieser Informatik-Stoff die Mathematik-Vorlesungen im Lehrplan. Aktuelles Wissen ersetzte Jahrhunderte altes Lehrbuchwissen. Das wiederum führte zu Fortschritten des Fachs im eigenen Land.

Walter Tichy forderte, dass wenigstens im Software-Engineering-Bereich keine Forschungsergebnisse ohne empirische Validierung veröffentlicht werden sollten. Er nahm deshalb Experimente mit Studierenden vor, wohl wissend dass diese nicht überzeugend sind, nicht echte Situationen darstellen. Um Größenordnungen besser wäre es, es könnten Erfahrungen aus echten Projekten gesammelt und ausgewertet werden. Hier setzen Dieter Rombach und das Fraunhofer-Institut in Kaiserslautern an. Von einer systematischen Analyse einer Vielzahl großer Projekte ist er noch weit entfernt. Eine mögliche Lösung wäre, dass zumindest alle öffentlichen Projekte ab einer gewissen Größenordnung verpflichtet werden, außer für Kunst auch einen kleinen Prozentsatz der Kosten für wissenschaftliche Begleitung und Evaluierung aufzuwenden. Das Ergebnis wäre zwar nicht so sichtbar wie die Kunst am Bau, aber hätte eine große Langzeitwirkung für das Land.

Längst werden kaum noch Informatik-Produkte in Deutschland entwickelt. Der Großteil wird importiert. Es besteht die Gefahr, dass es auch für gewisse Arten von Informatik-Anwendungen immer schwieriger wird, sie hierzulande für den Weltmarkt zu entwickeln. Wenn man mal von den betrieblichen Anwendungen absieht, deren Domäne nach wie vor SAP ist, dringt die Informatik gerade mit voller Wucht in den Bereich privater Anwendungen vor. Es sind zwei Richtungen von Anwendungen, die hier eine Rolle spielen. Es sind einerseits Massenprodukte, andererseits übergroße Systeme (engl. Ultra-large-scale systems). So gegensätzlich sie auch erscheinen, sie haben vieles gemeinsam. Es gibt keine klar definierten Anforderungen, noch gibt es einen planbaren Entwicklungsprozess. Ihr Markt ist riesig und ihre Lebensdauer beträgt Jahrzehnte. Sie sind nicht kontrollierbar und wachsen wie Pflanzen. Es handelt sich um komplexe technische und wirtschaftliche Prozesse, die automatisiert werden. Sie stellen das Rückgrat dar für leicht benutzbare Front-ends, häufig Apps genannt. Lehrbücher klassifizieren sie vielfach als Client-Server-Systeme. Das ist richtig aber viel zu ungenau.

Es ist kein Wunder, dass alle neuen Anwendungen, von denen in den letzten fünf Jahren die Rede war, nicht einmal aus Europa stammen. Namen wie Amazon, eBay, Facebook, Google, aber auch Apples iPhone und das iPad, werden bei uns vor allem von Kritikern öffentlich wahrgenommen. Wie Mertens mit Recht bemerkt, sind wir Deutsche in vieler Hinsicht besonders sensibel oder pingelig. Projekte mit gesellschaftlicher Relevanz müssen daher bei uns besondere Hürden überspringen (siehe Stuttgart 21). Von Steve Jobs, den ich in diesem Blog mehrmals gewürdigt habe, stammt die Einsicht, dass man Nutzer nicht nach Anforderungen fragen kann für ein Produkt, dass sie noch gar nicht für möglich halten. Als guter Ingenieur oder Informatiker muss man die Anforderungen der Nutzer antizipieren. Wie kann man das, ohne nah bei den Nutzern zu sein? ‚Nah bei den Menschen‘ sagen einige Politiker dazu.

Fazit: Die Wissenschaft kann nicht nur von der Praxis lernen, sie muss von ihr lernen. Machen wir in Deutschland keine interessanten und anspruchsvollen Projekte mehr, die es wert sind von Akademikern beachtet zu werden, dann muss es einem nicht nur um die deutsche Informatik bange werden, sondern um den Standort allgemein. Noch ist es nicht soweit.

Zusätzliche Referenzen

1. Mertens, P.: Schwierigkeiten mit IT-Projekten der öffentlichen Verwaltung. Informatik Spektrum 32,1 (2009), 42-49
2. Mertens, P.: Schwierigkeiten mit IT-Projekten der öffentlichen Verwaltung – Neuere Entwicklungen. Informatik Spektrum 35,6 (2012), 433-446