Source Reflection #2: Sprachverwirrung

Moderne Softwareentwicklung gleicht dem Turmbau zu Babel kurz nach der Sprachverwirrung. Im Projekt werden die unterschiedlichsten Sprachen gesprochen. Es lohnt sich, einmal genauer auf diese Sprachvielfalt zu schauen und zu prüfen, wer da eigentlich mit wem spricht.

In Pocket speichern vorlesen Druckansicht 14 Kommentare lesen
Lesezeit: 5 Min.
Von
  • Jörg Friedrich

Moderne Softwareentwicklung gleicht dem Turmbau zu Babel kurz nach der Sprachverwirrung. Im Projekt werden die unterschiedlichsten Sprachen gesprochen. Da sind natürlich die Fachsprache der Anwender und die Sprache des Managements zu nennen. Ein einzigartiges Sprachgewirr von Modellierungs-, Beschreibungs-, Analyse- und Programmiersprachen verursachen vor allem aber die eigentlichen Baumeister – Analysten, Designer, Programmierer und Tester. Es lohnt sich, einmal genauer auf diese Sprachvielfalt zu schauen und zu prüfen, wer da eigentlich mit wem spricht.

Der Zweck von Sprache ist bekanntlich die Kommunikation. Normalerweise tauschen sich die Gesprächspartner in der gleichen Sprache aus. Diese haben sie durch lange Übung in einer kulturellen Gemeinschaft gelernt und können sich mit ihr über Dinge verständigen, die sie außerhalb der Sprache gemeinsam beobachten oder für die sie sich gemeinsam interessieren. Dabei gibt es zwar hin und wieder Missverständnisse, weil der eine einen Begriff anders gelernt hat als der andere und ihm deshalb eine andere Bedeutung gibt, aber meist verstehen sich die Sprecher der gleichen Sprache recht gut – vor allem, wenn es ihre Muttersprache ist.

Mehr Infos

Source Reflection – die Kolumne

"Was tun wir hier eigentlich?" – Das wird sich schon mancher im Softwareprojekt gefragt haben. Wer so fragt, wird schnell philosophisch und kommt ins Staunen über das Selbstverständliche. Dieses Reflektieren macht Software nicht auf die Schnelle besser, aber auf lange Sicht ändert es die Art, wie man Problemen begegnet, und darum geht es in dieser Kolumne.

Programmiersprachen unterscheiden sich in vielem von den sogenannten natürlichen Sprachen, fast könnte man meinen, dass es ein großes Missverständnis sei, sie überhaupt als "Sprachen" zu bezeichnen. Manche meinen, diese künstlich erzeugten Sprachen seien eigentlich die idealen Sprachen, weil ihre Regeln und Begriffe so klar definiert seien, während die natürlichen Sprachen viele unklare Regeln und Abweichungen kennen, ganz zu schweigen von den Bedeutungen der Begriffe, die in den Alltagssprachen unpräzise und schwankend sind.

Beim genaueren Hinsehen fällt allerdings auf, dass es gerade einmal die Grammatik ist, die bei den technischen Sprachen der Softwareentwicklung präzise definiert ist. Wie die einzelnen Elemente miteinander verbunden werden dürfen, wie sozusagen die Worte zu Sätzen zusammenzusetzen und was die Bestandteile einer vollständigen Geschichte sind, das ist sowohl in UML als auch in SQL und in jeder Programmiersprache klar definiert. Um die Bedeutungen der konkreten Begriffe, seien es Klassen, Relationen, Objekte, Variablen oder Eigenschaften, zu bestimmen, braucht man aber wieder die natürlichen Sprachen, und mit ihnen kommt die ganze Verschwommenheit der natürlichen Sprachen wieder ins Projekt. Oftmals verdeckt die formale Präzision gerade die inhaltliche Unschärfe, vor allem während der Analyse- und Modellierungsphasen der Softwareentwicklung – mit fatalen Folgen für die Anforderungserfüllung.

Ein besonderer Unterschied zwischen natürlichen Sprachen und den künstlichen Sprachen der Softwareentwicklung wird deutlich, wenn man Sprecher und Hörer sowie ihre Kommunikation genauer betrachtet. Zunächst einmal fällt bei letzteren auf, dass es keine wirklichen Muttersprachler gibt, niemand hat eine Modellierungs- oder Programmiersprache auf die gleiche Weise erlernt wie die Sprache seiner Eltern. Auch die besten Designer, Analysten und Programmierer mussten diese Sprachen als Fremdsprachen lernen. Es ist, als wenn sich zwei Deutsche über bestimmte Themen auf Englisch unterhalten, etwa weil sie bestimmte Fachausdrücke eben nur auf Englisch gelernt haben.

Aber das ist noch gar nicht der wichtigste Punkt. In Softwareprojekten unterhalten sich zwar auch hin und wieder zwei Designer über die Softwarearchitektur und nutzen dabei UML, oder zwei Programmierer sprechen über die Implementierung eines Algorithmus und verwenden dafür Code-Fragmente. Das kann passieren und ist meistens unproblematisch, aber es ist nicht unbedingt notwendig. Für den Fortgang eines Entwicklungsprojekts ist es aber zwingend erforderlich, dass etwa der Analyst mit dem Anwender oder mit dem Programmierer spricht, und dabei kommt es regelmäßig, wenn auch manchmal unbemerkt, zu einer wahrhaft babylonischen Sprachverwirrung. Denn nun spricht einer, der seine Fachsprache recht sicher beherrscht, mit jemandem, der sie nie richtig gelernt hat, der sie nur vom Zuhören kennt und sie selbst nicht aktiv spricht. Selbst wenn die Anwender, die im Projekt mitwirken sollen, alle eine UML-Schulung besucht haben, kennen sie die Sprache nicht aus der eigenen aktiven Benutzung.

Die Konsequenz ist, dass der Hörer einen großen Teil seiner Aufmerksamkeit auf das Decodieren, das Rückübersetzen dessen, was dargestellt wird, in seine Muttersprache, verwenden muss. Es ist, als wenn man einen Film in der Originalsprache sieht, die man zwar gelernt hat, aber nicht wirklich aktiv spricht: Man hat ständig damit zu tun, sich die Dialoge zu übersetzen, und bekommt vom Sinn der Handlung nicht viel mit.

Sollte man also in Softwareprojekten auf Modellierungssprachen verzichten? In Schulungen vermitteltes UML für alle ist jedenfalls nicht ausreichend, um den Kommunikationserfolg zu sichern. Der optimale Weg hängt von der Projektgröße und von der Häufigkeit ab, mit der Anwender und Fachexperten in Projekte eingebunden werden. Wichtig ist schon, dass man sich der Sprachverwirrung immer bewusst ist und dass man sich genug Zeit für die Beseitigung von Verständigungsproblemen nimmt. Ob die Geschichte, die ein UML-Diagramm erzählt, wirklich die ist, die der Anwender in der Praxis erlebt, lässt sich allerdings am besten dadurch sichern, dass man sie gemeinsam aufschreibt, sich der Analyst also als eine Art Ghostwriter des Anwenders versteht. Das gilt genau genommen auch noch für den Programmierer, der mit der Maschine "spricht".

Jörg Friedrich
ist Philosoph und Geschäftsführer eines Münsteraner Softwarehauses. Im vergangenen Jahr erschien sein Buch "Kritik der vernetzten Vernunft".
(ane)