Kategorie-Archiv: Sprache

Veröffentlicht am von

Wo liegt das Epizentrum?

Das Zentrum eines Erdbebens liegt üblicherweise unterhalb der Erdoberfläche, weshalb man es auch bisweilen als Hypozentrum bezeichnet. Das Epizentrum hingegen bezeichnet den Ort auf der Erdoberfläche, der dem (Hypo-)Zentrum am nächsten liegt. Oder für Mathematiker: der Punkt an dem die Gerade, die durch Hypozentrum und Erdmittelpunkt definiert wird, die Erdoberfläche schneidet.

Wenn also New York als „Epizentrum der Corona-Krise“ bezeichnet wird, (zur Krise siehe hier), wo liegt dann das Zentrum? Die Frage ergiebt keinen Sinn, weil der Begriff falsch gewählt ist. Man könnte statt dessen vom Brennpunkt sprechen oder ganz einfach vom Zentrum. Mit etwas Nachdenken finden sich noch mehr Worte die korrekt benennen was hier zu benennen ist — aber eben nicht das Wort „Epizentrum“. Das ist in der Tat ein wunderbar eklatantes Beispiel, da der Begriff nicht — wie sonst — nur einfach schlecht gewählt, sondern schlicht und ergreifend falsch ist.

Warum ist das überhaupt wichtig? Und warum soll das für Code-Qualität wichtig sein? Die erste und wichtigste Regel in der Software-Entwicklung ist meiner Meinung nach

Versuche jedes Ding so zu bezeichnen, daß der Bezeichner das Ding so genau wie möglich beschreibt.

Das gilt für jedes Ding: Konzepte, Objekte, Funktionen — was auch immer. Wenn ich Äpfel möchte und von Birnen spreche, dann kommt nichts vernünftiges dabei heraus. Sobald ich aber versuche die Dinge genaustmöglich zu beschreiben, werde ich jede Ungenauigkeit die sich nicht korrigieren läßt als Fehler in meiner gedanklichen Konstruktion erkennen. Das Formulieren von Gedanken formt Gedanken.

Wenn ich mal jemanden auf den falschen Gebrauch eines Wortes hinweise, bekomme ich fast immer die gleiche Antwort: Was macht das schon? Du weißt doch was ich meine.

Wo aber ist die Grenze? Wann ist die Ungenauigkeit so groß daß ein Mißverständnis entsteht? Wieviel Ungenauigkeit kann ich mir in einer Anforderung erlauben, bevor die Umsetzung aufhört den Wünschen des Auftraggebers zu entsprechen?

Das mag ja sein, aber man kann doch darüber sprechen und Mißverständnisse klären, oder?

Natürlich kann man das, aber es setzt voraus, daß der Empfänger der Nachricht immer davon ausgeht daß der Sender nicht recht weiß wovon er eigentlich spricht. Klingt das nach der Grundlage für eine ausgewogene Kommunikation? Und was ist falsch daran vom Verfasser eines Textes — sei es eine eMail, ein Zeitungsartikel oder eine Anforderung — zu verlangen daß er sich darum bemüht zu sagen was er meint? Hat der Hörer nicht ein Anrecht darauf, daß der Sprecher versucht ihn zu erreichen?

Ok, das hört sich ja nun nicht völlig verkehrt an. Und wenn es wichtig ist, also wenn es wirklich darauf ankommt, dann muß man sich natürlich um Genauigkeit bemühen. Aber ist das ein Grund den ganzen Tag mit dem Wörterbuch unter dem Arm herumzulaufen um jeden Malapropismus damit totzuprügeln?

Man frage sich: Wie soll ich — wenn’s drauf ankommt — den genauen Begriff finden, wenn ich das nicht vorher — wenn’s also nicht so drauf ankommt — trainiert habe? Ist es nicht effizienter so ausdauernd zu trainieren, daß die Anwendung zur natürlichen geistigen Bewegung wird, die keine zusätzlichen intellektuellen Kräfte durch Bewußtmachen und Nachdenken verschwendet? Die Sprache kleidet meine Gedanken. Ist es nicht wünschenswert, mit den Worten jederzeit genau das ausdrücken zu können was man denkt? Genauigkeit der Sprache ist — wie Qualität — mehr eine Geisteshaltung, weniger eine Technik.

Und wenn mir der geneigte Leser nun vorwerfen möchte meine Sprache sei manieriert und nehme überhaupt keine Rücksicht auf den Leser, dann hat er damit vielleicht nicht ganz unrecht. Aber ganz sicher hat er dann verstanden, warum es mir so wichtig ist was ich da denke und warum ich mich stets darum bemühe, es mit meinen Worten in Einklang zu bringen.

Veröffentlicht am von

Sprache und Qualität

Was hat Sprache mit Qualität zu tun? Was hat sie insbesondere mit Code-Qualität zu tun? Bei der (natürlichen) Sprache geht es — wie beim Code — nicht nur darum, einen Sachverhalt irgendwie auszudrücken. Es gilt, ihn so auszudrücken, daß er seien Zweck möglichst gut erfüllt. Selten geht es darum, einfach nur Information zu übermitteln, man will auch überzeugen, beeindrucken, Gefühle beim Leser wecken. Und selbst wenn es tatsächlich nur um die Information geht, wird es nötig sein, die Formulierung dem Ziel-Publikum anzupassen. Ein Text kann also einen Zweck mit mehr oder weniger Qualität zu erfüllen trachten.

Daß man von Computer-Sprachen spricht, ist mehr als eine zufällige Homonymie. Zwar geht es in erster Linie darum, einen Sachverhalt exakt und eindeutig darzulegen, aber je nach dem welche Konstrukte man für die Implementierung wählt ist das Ergebnis für den Menschen mehr oder weniger verständlich. Warum ist das wichtig? Die Maschine interessiert sich nicht dafür wie das Programm aussieht, sie führt aus was ihr gegeben wird. Beim Programmierer ist das anders

Code wird für Computer geschrieben, aber für Menschen formuliert

So sinnvoll es im Umgang mit natürlicher Sprache ist über die geeignete Formulierung nachzudenken, so sinnvoll ist es, beim Formulieren von Computer-Code über die zukünftigen Leser nachzudenken. Wie Robert C. Martin ganz richtig festgestellt hat, verbringt der Programmierer wesentlich mehr Zeit damit Code zu lesen — und zu verstehen — als damit ihn zu schreiben.

Ein anderer Aspekt der natürlichen Sprachen ist nicht so einfach auf die Computer-Sprachen zu übertragen:

Die Grenzen meiner Sprache bedeuten die Grenzen meiner Welt.

„Ludwig Wittgenstein“

Computer-Sprachen sind in der Regel Turing-vollständig. In jeder (vollständigen) Computer-Sprache läßt sich alles formulieren, was sich mit einer Turing-Maschine berechnen läßt und umgekehrt. Das heißt, daß alle Computer-Sprachen — ihren theoretischen Möglichkeiten nach – gleichmächtig sind; keine „kann mehr“ als irgendeine andere. Inwiefern begrenzt aber dann die Sprache die Welt des Programmierers?

Wer schon einmal versucht hat auch nur eine Addition mit einer Turing-Maschine zu berechnen, weiß was für eine enormer Unterschied zwischen Computer-Sprachen besteht. Nutzt man zur Lösung eines Problems eine Sprache die dafür geschaffen oder gar daraufhin optimiert wurde, sehen die Programme ganz anders aus. Der Code ist kompakter, leichter zu lesen und schneller zu verstehen, umfangreichere Probleme lassen sich damit lösen.

Das soll uns aber nicht in falsche Sicherheit wiegen. In jeder Sprache lassen sich unverständliche Programme schreiben. Ich jedenfalls kenne keine Sprache die das unmöglich macht. Man kann unter „Sprache“ auch die Art und Weise verstehen, wie man die Sprache einsetzt: Spreche ich „sauberes“ Deutsch oder bin ich nachlässig in Grammatik und Ausdruck? Wähle ich die passenden Worte oder einfach Worte die eben nur „ungefähr“ das ausdrücken was ich zu denken glaube?

Schlecht formulierter Code ist nicht nur schlecht zu verstehen. Er ist in der Regel auch schlecht zu ändern und zu erweitern. Schlechte, schlampige Sprache –- im Sinne der Verwendung -– schränkt den Programmierer ein; die Sprache — bzw. die Verwendung derselben — bestimmt die Welt des Programms.

Je mehr Sorgfalt man in die Formulierung legt, desto höher die Qualität des Textes — oder des Codes. Die Beschäftigung mit Sprache — ob natürlich oder künstlich — ist für den qualitätsorientierten Entwickler eine Notwendigkeit.

Veröffentlicht am von

Was ist eigentlich eine Krise?

Die Frage kam mir in den Sinn, als mir mal wieder der Begriff „Software-Krise“ über die Weg lief. Ein Begriff mit dem ich nie richtig glücklich war, nicht nur, aber eben auch weil er in meinen Augen falsch gewählt ist; ein misnomer wie man im Englischen sagen würde. Was also ist eine Krise? Die Antwort ist schnell gefunden, man muß sie nur suchen…

Der Begriff ist über das Lateinische zu uns gekommen und bedeutet im Griechischen „Scheidung“ oder „Entscheidung“. Er leitet sich vom Verb krinein her, das „richten“ oder „entscheiden“ bedeutet. Seine erste Verwendung fand er in der Medizin. Dort versteht man unter einer Krise den Moment im Krankheitsverlauf, in dem die Krankheit ihren Höhepunkt erreicht und es sich entscheidet, ob der Patient leben oder sterben wird.

In dieser Bedeutung läßt sich der Begriff in andere Kontexte übertragen in denen er eine Situation bezeichnet in der ein Umstand soweit eskaliert ist, daß eine Entscheidung getroffen muß. Eine Entscheidung darüber ob die Entwicklung weitergeht oder versucht werden soll sie in eine andere Richtung zu lenken.

Ein gutes Beispiel ist die Cuba-Krise im Herbst 1962. Die Stationierung sowjetischer Atom-Raketen in Kuba stellte die US-Regierung vor die Entscheidung eine permanente unmittelbare Bedrohung zu akzeptieren oder nicht. Gleichzeitig entschied die Handhabung der Krise über den Ausbruch eines atomaren Weltkriegs. Wie die Wikipedia richtig bemerkt, läßt sich eine Krise meist erst nach ihrer Bewältigung als solche identifizieren.

Eine Krise ist also im Grunde genommen ein Punkt auf der Zeitachse. Sie markiert den Kulminationspunkt der Ereignisse, mathematisch gesehen das — gegebenenfalls lokale — Maximum einer Kurve. Nun kann man argumentieren, daß sich dieses Maximum auch über einen gewissen Zeitraum erstrecken könnte. Aber die Bedeutung des Begriffs verlangt, daß eine Entscheidung getroffen wird — auch wenn es die Entscheidung ist keine Entscheidung zu treffen.

Was bezeichnet nun der Begriff „Software-Krise“? Geprägt wurde er auf einer Konferenz die die NATO 1968 in Garmisch abhielt. Tatsächlich wurde dabei auch die alternative Bezeichnung „software gap“ verwendet:

There is a widening gap between ambitions and achievements in software engineering.

Im Wesentlichen ging es darum, daß die Komplexität der Software immer schneller anwuchs und die Software-Ingenieure mit den Mitteln der Zeit mit dieser Komplexität immer schlechter fertig wurden. In den Augen der Konferenz-Teilnehmer — oder zumindest einem Teil derselben — wurde es notwendig, Technik und Arbeitsweise der Software-Entwicklung zu ändern, damit sie mit den steigenden Anforderungen Schritt halten kann. Wenn also der Zeitpunkt für eine Entscheidung — oder Entscheidungen — gekommen war, warum dann nicht von einer Krise sprechen?

Wenn damals der Kulminationspunkt erreicht war, kann man von einer Krise sprechen. Aber es liegt im Wesen der Krise, daß eine Entscheidung — oder Nichtentscheidung — zum Ende derselben führt; in der einen oder anderen Art und Weise. Entweder hätte eine Entscheidung über die Software-Technik den Patienten gerettet oder die weitere Entwicklung hätte in eine Katastrophe geführt. Die Katastrophe ist ausgeblieben — zumindest nach meinen Kenntnisstand. Daher wage ich zu behaupten, daß die Entwicklung der Software-Entwicklung die Krise — wenn sie denn eine solche war — überwunden hat.

Wenn eine Situation über fünfzig Jahre anhält, ohne daß eine Entscheidung zu ihrer Änderung getroffen wird, dann handelt es sich nicht um eine Krise, sondern um einen Zustand.

Das, was heutzutage als „Software-Krise“ bezeichnet, ist ein Zustand und er unterscheidet sich durchaus von der Situation die Ende der 60er Jahre bestand. Die Zeit ist nicht stehen geblieben, Konzepte wurden verbessert und angepaßt, es stehen unglaubliche Mengen von Hilfsmitteln zur Verfügung. Die Entwicklung zeigt, daß die Software-Entwicklung mit den Anforderungen fertig werden kann. Das Problem liegt in den immer weiter steigenden Anforderungen an Kosten und Geschwindigkeit. Software muß immer schneller und immer billiger produziert werden, das hat Konsequenzen. Aber noch ist der Kulminationspunkt nicht erreicht und daher sollte man nicht von einer Krise sprechen sondern von einem Zustand.