Na endlich! Auf diesen Artikel haben Sie bestimmt lange gewartet! Wir erklären, wie die Fehler ins Programm kommen, warum bereits funktionierende Teile wieder kaputt gehen können und warum es manchmal so schwer ist, die Probleme unter Kontrolle zu bringen.
Manchmal kann es sehr frustrierend sein, wenn mal wieder die Bug-Liste länger und länger wird. Man fragt sich als Nicht-Programmierer vielleicht, wie es eigentlich dazu kommen kann, dass es derart viele Fehler in der Software gibt. Andere Firmen scheinen das ja auch irgendwie zu meistern. Und warum gehen eigentlich Sachen kaputt, die vorher korrekt funktioniert haben? Was machen die Codierer eigentlich den ganzen Tag für Mist?
Die Wahrheit ist, dass es sehr viele Gründe für Bugs im Code gibt. Im Folgenden soll auf die einzelnen Ursachen eingegangen und Lösungswege aufgezeigt werden.
Wir haben an der Stelle aber ein kleines Problem: Die Arbeit an Code ist extrem abstrakt, beinhaltet sehr viele komplizierte Mechanismen, die man als Außenstehender nur schwer begreifen kann (wenn man sich nicht wenigstens ein oder zwei Jahre mit dem Thema auseinander gesetzt hat) und man stößt auf Probleme, die es bei anderen Arbeiten so nicht gibt. Wir wollen es trotzdem mal versuchen.
Bugs sind normal, wirklich.
Grundsätzlich gilt, dass Fehler in einer Software nichts ungewöhnliches sind. Es ist logisch, dass je großer, je komplexer, je vielseitiger ein Programm ist, desto mehr Bugs enthalten sein müssen. Mit wachsender Zahl an Möglichkeiten und Optionen gibt es mehr, was man unter Kontrolle bringen muss. So wie es beim Fahrzeugbau zu Montagefehlern kommen kann, kann es passieren, dass ein Programmierer etwas falsch codiert – wir haben zwar göttliche Kräfte, sind aber auch nur Menschen. Während aber die falsch montierten Autos nur an ein paar Kunden ausgeliefert werden, erhalten beim Programm alle Kunden den fehlerhaften Code. Dafür kann man die Fehler leichter korrigieren ;-).
Trotzdem scheint es bei anderen Softwarefirmen weniger Probleme zu geben. Aber das ist ein Trugbild. Als Außenseiter hat man keinen Einblick auf die tatsächliche Liste an Problemen bei anderen. Man hat nur das subjektive Empfinden und kennt selber auch nicht alle Bugs in Fremdprogrammen. Auch Google und Facebook bleiben von Fehlern nicht verschont. Sie setzen aber Strukturen ein, die die Gesamtzahl an Fehlern deutlich verringert (dazu später mehr).
Manchmal sind Bugs keine Bugs
Programmierer sind öfters mal – sagen wir – überrascht, was manchmal als Bug durchgeht. Nicht selten liegt aus rein objektiver Sicht kein Fehler vor. Das kann beispielsweise sein, wenn die ursprüngliche Funktionsdefinition unzureichend war. Wenn man dem Codierer sagt, die Software soll Word-Dateien lesen und man merkt, dass Kunden lieber Excel-Dateien verwenden und sich wundern, warum das nicht geht, dann ist es nicht Schuld des Programmierers, dass das Programm keine Excel-Dateien verarbeiten kann, auch wenn es für den Kunden wie ein Fehler aussieht.
Es gibt noch viele weitere Beispiele. Wenn man etwa das subjektive Gefühl hat, dass das Programm zu langsam ist, dann liegt auch kein Fehler vor.
Ein Bug ist wirklich nur dann ein Bug, wenn das Programm etwas anderes macht, als das, was man den Codierern zuvor exakt vorgegeben hat (und auch nur dann, wenn sich die Definition nicht alle drei Stunden ändert, weil fünf Leute vorgaben machen oder der Kunde nicht weiß, was er eigentlich möchte/braucht). Wenn der Programmierer widersprüchliche oder falsche Anweisungen bekommt, woher sollte er denn wissen, was er wirklich machen muss? Wie soll er so eine einheitliche, stabile Programmstruktur aufbauen? Kann er sich so überhaupt Zeit nehmen, es richtig zu machen? Das ist übrigens auch der Grund, weshalb es sinnvoll ist, dass ein Programmierer die Anweisungen immer nur von einem einzigen P. O. (Product-Owner) erhält und von sonst niemandem. Gemeint ist nicht „immer nur einer gleichzeitig“ sondern „es gibt überhaupt nur eine Person, die beauftragen darf“.
Keine Tests sind keine gute Idee
Auch heute noch sparen viele Firmen an den Tests, aber dann muss man auch mit den Konsequenzen leben. Das Schlimme ist, dass manchmal auch Programmierer blind gegenüber den Vorteilen von Tests sind, nach dem Motto
„Wir bekommen das auch irgendwie so schon hin, dass die Software läuft.“
(siehe oben „Codierer sind auch nur Menschen“). Man sieht: Nö, läuft nicht. Gerade deshalb muss man etwas Zeit und Geld in Tests investieren, auch wenn man die Vorteile nicht direkt zu spüren bekommt. Das Kosten-Nutzen-Verhältnis spricht jedenfalls für sich. Ich weiß, es ist immer schwer, etwas zu erklären bzw. zu vermitteln, was nur sehr indirekt wirkt und erst nach einer gewissen Zeit Ergebnisse zeigt. Allerdings können Tests unbestechlich beweisen, dass etwas Bestimmtes funktioniert oder eben nicht. Je mehr man testet, desto weniger Fehler entgehen einem. In einer perfekten Welt würde man sogar die Tests vor dem eigentlichen Code erstellen. Sobald der Code den Test besteht, gilt er als fertig. Eine bessere Vorgabe für das, was er machen soll, kann sich ein Programmierer eigentlich nicht wünschen – und keine Seite kann sich herausreden! Außerdem können Tests ja immer wieder ausgeführt werden, auch nach ein oder zwei Jahren. Und gute Tests laufen automatisch, sodass man schlicht einen kleinen Rechner aufstellen muss, der ganz alleine herumrödelt und Sie auf Fehler hinweist, bevor es die Kunden tun. Dazu kommt, dass manuelle Tests aufwendig sind, nervig noch dazu und irgendwann hat niemand mehr Zeit und Lust, die Software per Hand intensiv zu prüfen.
Alter Code sind Altlasten
Warum sollte alter Code Schwierigkeiten machen? Er ist doch bewährt, weil viel-benutzt! Das ist aber falsch gedacht. Software ist wie ein lebender Organismus. Sie wächst, Dinge verwachsen miteinander, Teile verändern sich, Verbindungen lösen sich, Sachen werden entfernt. Das bedeutet, dass sich Funktionen absichtlich oder unabsichtlich ständig dynamisch verändern, vor allem wenn ein ganzes Team am Produkt arbeitet. Je größer die Abhängigkeiten von Features in einem Programm sind, desto stärker und unberechenbarer sind die Ergebnisse, sobald es eine Änderung an einer Stelle gibt. Und alter Code tendiert durch Vielbenutzung einfach dazu, sich an alle möglichen andere Stellen zu koppeln (= Abhängigkeit).
Es ist wie beim Hausbau: Am Anfang war ein Gebäude. Als es zu klein war, hat man an alle möglichen Seiten weitere Gebäude angebaut. Und sobald das Mittelteil abgerissen werden muss, bekommen wir Probleme im ganzen Komplex.
Leider altert Code mit der Zeit. Zum einen erkennt man langsam aber sicher, dass man einen Teil besser hätte realisieren können (leichter wartbar, leichter erweiterbar, bessere Testbarkeit, bessere Performanz), zum anderen hat man immer wieder kleine Eingriffe (zur Korrektur oder um die Funktionalität zu erweitern) und diese werden mit zunehmender Anzahl zur Pfusch-Bastelarbeit. Nach der zehnten Schönheitsoperation sieht halt jeder aus wie ein Zombie. Darum führt kein Weg daran vorbei, große Bereiche des Codes nach ein paar Jahren ganz und gar einzureißen und komplett neu zu bauen. Um dabei die Garantie zu haben, dass der neue Code mindestens genauso gut ist wie der alte, braucht man Mechanismen zur Qualitätssicherung (siehe oben: Die damaligen Tests kann man wiederverwenden, wenn sich eine Funktion nicht ändern soll).
Falsche Arbeitsweise führt zu falscher Funktionalität
Dieses Thema habe ich in den obigen Absätzen bereits angeschnitten. Auch die Art und Weise wie das Team arbeitet hat selbstverständlich Auswirkungen auf die Qualität des Produkts. Das ist jedoch in vielen anderen Berufen genauso. Viele Faktoren können letztlich dazu führen, dass man die Professionalität vergisst und sich wild durchkämpft. Damit lindert man nur die Symptome, die Krankheit lässt sich aber nur durch eine kluge und sachliche Vorgehensweise beenden.
Stress und Zeitmangel: Wenn die Kunden ganz dringend ein Feature brauchen, das vielleicht sogar schon bezahlt ist, und ohne welches sie ganz und gar nicht produktiv arbeiten können, dann wird Druck auf die Codierer ausgeübt. In vielen Firmen ist das sogar leider die Regel. Allerdings, wenn man Code (also etwas Handwerkliches, das man nicht einfach so zusammenkopieren kann) wie am Fließband produzieren muss, dann sollte man sich auch nicht über eine schlechte Qualität wundern. Natürlich lassen sich solche Situationen nicht vermeiden. Dafür wurde der Begriff „technische Schulden“ erfunden. Man macht also zunächst etwas, was eine Verpflichtung schafft, dass man es in besseren Zeiten wieder in Ordnung bringt. Dafür muss es aber auch bessere Zeiten geben, sonst ist man irgendwann technisch insolvent.
Wissensblase: Sehr viele Berufe haben es so an sich, dass sich das Wissen schnell weiterentwickelt und es immer wieder neue Methoden, Werkzeuge, Erfahrungen und Prinzipien gibt. Selbstverständlich muss man nicht jede Sau reiten, die durchs Dorf getrieben wird. Aber gerade in der Programmierung erweisen sich manche Neuigkeiten nach ein paar Jahren als der richtige Weg. Diesen Weg sollte man konsequenterweise bereit sein, zu beschreiten. Denn wenn man nicht bereit ist, sich weiter zu entwickeln und damit sich und die Software zu verbessern, kann man schon bald nicht mehr mit der Konkurrenz mithalten, die plötzlich flexibler und schneller Features implementiert, günstiger produziert und eine performantere und stabilere Software präsentiert – und der Ahnungslose rätselt, warum das so ist.
Teamfähigkeit: Wenn jeder sein eigenes Süppchen kocht und am Schluss alles zusammengekippt wird, wird es schlecht schmecken. Das gilt für Programmierer unter sich, denn wenn man sich nicht auf bestimmte Frameworks (also fertige Features, die man kaufen/herunterladen und leicht einbinden kann) und Code-Konventionen (Schreib- und Strukturierungsstil) einigt, dann wird die Software zu einem undurchsichtigen Knäuel von Gekröse. Das gleiche gilt für Zuständigkeiten und die Aufteilung der Bereiche und Aufgaben. Es gilt jedoch auch für die Zusammenarbeit zwischen Codierern und dem Rest der Firma (siehe oben: ein einziger P. O. pro Software/Produkt/Produkt-Abschnitt).
Werkzeuge: Im Vergleich zu anderen Industriezweigen ermöglicht die Software-Branche eine vergleichsweise günstige Einrichtung eines Arbeitsplatzes. Mit einem guten Rechner und drei Monitoren hat man bereits den Großteil. Allerdings sollte man den Codierern auch darüber hinaus Möglichkeiten bieten. So sollten Geld und Zeit eingeplant werden für: Test-Server, Software-Tools (für Tests, zum Messen von Code-Werten usw.), ergonomische Maus und Tastatur (Gesundheit!), Weiterbildungen und Fachliteratur.
Wichtig ist es auch, eine Balance zwischen Sicherheit und Legalität zum einen und Freiheit zum anderen zu finden. Niemand sollte beispielsweise an der Firewall vorbei etwas in das Firmennetzwerk schleusen können. Auf der anderen Seite müssen Programmierer jedoch spontan und schnell Software-Tools herunterladen und installieren können, um sich just-in-time die Hilfswerkzeuge anzuschaffen, die sie zum Lösen ihrer Probleme brauchen. Das können Code-Analyse-Werkzeuge sein, aber auch Editoren mit Formatierungs- und Markierungsfunktion. Die Lösung hierfür ist, einen System-Administrator als ständigen Ansprechpartner direkt in der Firma vor Ort zu haben. Dessen Reaktionszeit darf die Feierabendgrenze auf keinen Fall überschreiten, sonst droht Produktionsstillstand!
Fallbeispiel: Steuerarten
Schauen wir und doch mal ein Szenario an. Nehmen wir an, wir bieten derzeit eine Software auf dem Markt an, mit der man Dienstleistungen projektieren und Rechnungen schreiben kann. Zuerst sollte es eine einfache und günstige Alternative zu den Produkten der Big Player werden. Nachdem jedoch immer mehr Kunden dazugekommen sind – teils auch Großkunden – stehen wir unter dem Druck, immer wieder Anpassungen vorzunehmen, damit diese Kunden die Software z. B. auch in ausländischen Zweigstellen verwenden können.
Immer wieder wollten Kunden nicht nur die deutsche Steuerart für Dienstleistungen zur Rechnung hinzufügen, sondern alternativ auch die polnische, portugiesische, spanische, italienische…
Unser Neukunde möchte das Programm in Frankreich verwenden.
Ein Hinweis noch: Sie müssen die Code-Beispiele nicht verstehen. Es reicht hier völlig, wenn Sie den Code (der keine richtige Programmiersprache darstellt; sog. Pseudocode) einfach auf sich wirken lassen (bezüglich Übersichtlichkeit, Umfang, Struktur etc.).
Kunden-Betreuer: „Hey, unser neuer Kunde braucht die französische Steuerart zur Auswahl. Der ist schon ein bisschen genervt, dass wir uns erst jetzt, zwei Monate nach dem Kauf, um ihn kümmern. Ich habe ihm gesagt, dass das bis Ende der Woche eingebaut ist. Könntest du das bitte machen? Es wäre sehr wichtig.“
Programmierer: „Naja, das ist nicht ideal, weil wir noch andere dringende Sachen auf der To-Do-Liste haben. Ich kann aber mal schauen, ob ich das irgendwo dazwischenquetsche.“
Kunden-Betreuer: „Danke! Wie gesagt, das ist schon wichtig.“
Der Programmierer schaut in den Code:
function calculateRechnung(preis, land) returns number{
if (land.is("Deutschland")){
preis = preis * 1.05;
} else if (land.is("Polen")) {
preis = preis * 1.08;
} else if (land.is("Portugal")) {
preis = preis * 1.05;
} else if (land.is("Spanien")) {
preis = preis * 1.11;
} else if (land.is("Italien")) {
preis = preis * 1.02;
}
return preis;
}
Programmierer: „Hm, ja, das ist jetzt nicht gerade ultra vorbildlich. Aber das sah früher einmal besser aus.“
function calculateRechnung(preis) returns number{
return preis * 1.05;
}
Programmierer: „Das war vor den anderen Ländern. Ok, aber so wie es jetzt ist, könnte es mal zum Problem werden. Allerdings habe ich gerade echt keine Zeit dafür und es muss ja auch schnell gehen. Dann klatschen wir Frankreich einfach nur mit dazu…“
function calculateRechnung(preis, land) returns number{
if (land.is("Deutschland")){
preis = preis * 1.05;
} else if (land.is("Polen")) {
preis = preis * 1.08;
} else if (land.is("Portugal")) {
preis = preis * 1.05;
} else if (land.is("Spanien")) {
preis = preis * 1.11;
} else if (land.is("Italien")) {
preis = preis * 1.02;
} else if (land.is("Frankreich")) {
preis = preis * 1.15; }
return preis;
}
Nach einem Monat hat sich der Kunde entschlossen, die Software auch im französisch-sprachigen Teil Kanadas einzusetzen.
Product-Owner: „Unser Kunde möchte das Programm jetzt auch in Kanada einsetzen. Das heißt, wir brauchen noch die Steuerart „Kanada“ mit 14% Aufschlag. Ich würde das gerne für die nächste Woche einplanen.“
Programmierer: „In Ordnung, können wir machen.“
Der Programmierer schaut ein paar Tage später wieder in den Code:
function CalculateRechnung(preis, land) returns number{
if (land.is("Deutschland")){
preis = preis * 1.05;
} else if (land.is("Polen")) {
preis = preis * 1.08;
} else if (land.is("Portugal")) {
preis = preis * 1.05;
} else if (land.is("Spanien")) {
preis = preis * 1.11;
} else if (land.is("Italien")) {
preis = preis * 1.02;
} else if (land.is("Frankreich")) {
preis = preis * 1.15;
} else if (land.is("Belgien")) {
preis = preis * 1.10;
} else if (land.is("Dänemark")) {
preis = preis * 1.07;
} else if (land.is("Holland")) {
preis = preis * 1.09;
} else if (land.is("Luxemburg")) {
preis = preis * 1.10;
}
return preis;
}
Programmierer: „Na hoppla! Wie kann denn das sein? Da hat wohl jemand einfach das komplette Benelux-Gebiet reingepackt und sich nicht einmal angestrengt, den Code besser zu machen. Das kann doch nicht endlos so weiter gehen! Wer soll denn das nach der halben Weltkugel noch lesen können? Und der Code für die Multiplikation ist auch pro Land vorhanden. Das könnte man doch zusammenziehen! Refactoring!“
enumeration Tax{
GERMANY,
PORTUGAL,
SPAIN,
ITALY,
FRANCE,
BELGIUM,
DENMARK,
NETHERLANDS,
LUXEMBOURG,
KANADA;
function getTaxFactor() returns number{
switch (this)
{
case GERMANY: return 1.05;
case PORTUGAL: return 1.08;
case SPAIN: return 1.05;
case ITALY: return 1.11;
case FRANCE: return 1.02;
case BELGIUM: return 1.15;
case DENMARK: return 1.10;
case NETHERLANDS: return 1.07;
case LUXEMBOURG: return 1.09;
case KANADA: return 1.14;
}
}
}
function calculateBill(price, countryTax) returns number{
return price * countryTax.getTaxFactor();
}
Was ist hier nun passiert? Der Entwickler hat den Code auf zwei Code-Teile gesplittet und damit nach Aufgaben aufgeteilt: Auf der einen Seite haben wir das Abbilden von Ländern auf den einzurechnenden Faktor, auf der anderen Seite haben wir die Formel zur Berechnung an sich. Dadurch findet man sich besser zurecht, weil man nicht nach bestimmten Stellen suchen muss. Eine Aufgabe = eine Stelle = gut (heißt in der Fachsprache SRP, Single Responsibility Principle).
Außerdem hat der Programmierer den Code nun komplett und konsequent ins Englische übersetzt. In Anbetracht der Tatsache, dass man vielleicht irgendwann auch Mitarbeiter hat, die kein Deutsch sprechen, ist das eine gute Entscheidung. Denn ein solcher Kollege würde nicht „Mitarbeiter“, sondern „Meiterbeiter“ schreiben. Der Code wäre dann nicht deutsch, nicht englisch, sondern Quatsch. Und nach Quatsch-Begriffen kann man nicht gezielt suchen und man versteht sie auch nicht.
Aber: Ich weiß nicht, ob es Ihnen aufgefallen ist. Entgegen seiner Nationalhymne ist Polen nun verloren. Dadurch haben sich auch die Faktoren aus Versehen verschoben. Gäbe es für diese Funktionalität einen Code-Test (auch Unit-Test genannt), dann wäre das dem Entwickler aufgefallen. So aber ist eine seit langem funktionierende Stelle plötzlich kaputt gegangen.
Es kommt aber noch härter:
Kunden-Betreuer: „Der Kunde meint, das funktioniert noch nicht.“
Programmierer: „Ich habe das aber einmal ausgeführt und da ging es. Komisch. Was genau geht denn nicht?“
Kunden-Betreuer: „Es wird der falsche Faktor genommen. Für Dienstleistungen beträgt die Steuer 7 %.“
Programmierer: „Mein P.O. meinte aber 14 %.“
Kunden-Betreuer: „Nein, der Kunde meint 7 %.“
enumeration Tax{
GERMANY,
PORTUGAL,
SPAIN,
ITALY,
FRANCE,
BELGIUM,
DENMARK,
NETHERLANDS,
LUXEMBOURG,
KANADA;
function getTaxFactor() returns number{
switch (this) {
case GERMANY: return 1.05;
case PORTUGAL: return 1.08;
case SPAIN: return 1.05;
case ITALY: return 1.11;
case FRANCE: return 1.02;
case BELGIUM: return 1.15;
case DENMARK: return 1.10;
case NETHERLANDS: return 1.07;
case LUXEMBOURG: return 1.09;
case KANADA: return 1.07;
}
}
}
Product-Owner: „Ich wollte das gerade dem Kunden zeigen, aber es funktioniert plötzlich nicht mehr. Es sind jetzt so um die 7 %.“
Programmierer: „Ja, der Kunden-Betreuer meinte, es müssen 7 % sein. Das hat der Kunde gesagt.“
Product-Owner: „Komisch. In der E-Mail steht, dass es 14 % sind.“
Programmierer: „Ihr müsst euch schon entscheiden.“
Es wird also eine Online-Konferenz mit dem Kunden einberufen.
Product-Owner: „Hallo. Wir haben hier widersprüchliche Angaben über den genauen Betrag der Steuer für Dienstleistungen in Kanada. Sind es 7 % oder 14 %?“
Kunde: „Es gibt fünf Steuerarten, je nach Ware oder Dienstleistung: 0, 5, 7, 11 und 14 %.“
Kunden-Betreuer: „Also hatte ich Recht.“
Product-Owner: „Und ich auch.“
Kunde: „Hätten Sie das nicht einfach googlen können? Warum muss ICH Ihnen das erklären?“
Programmierer: „…“
Der Programmierer muss sich jetzt etwas ausdenken.
- Er könnte entweder eine zweite Kategorie, neben dem Land, einführen – das wäre Code-mäßig eher kompliziert, würde länger dauern, aber dafür hätte man eine saubere Trennung der Kategorisierung. Das ist insbesondere nützlich, wenn in Zukunft noch mehr Kategorien dazukommen (z.B. „Preisfaktor für Großleistungen“, „Famous-Client-Factor“ etc.).
- Er könnte einfach die Liste mit Kanada-Varianten erweitern. Damit vermischt man Länder und Dienstleistungsarten, bringt somit mehr Chaos in den Code, aber es geht schneller und leichter.
Drei Mal dürfen Sie raten…
enumeration Tax{
GERMANY,
PORTUGAL,
SPAIN,
ITALY,
FRANCE,
BELGIUM,
DENMARK,
NETHERLANDS,
LUXEMBOURG,
KANADA_HEALTH,
KANADA_FOOD,
KANADA_REPAIR,
KANADA_SERVICE,
KANADA_PRODUCTIVE;
function getTaxFactor() returns number{
switch (this) {
case GERMANY: return 1.05;
case PORTUGAL: return 1.08;
case SPAIN: return 1.05;
case ITALY: return 1.11;
case FRANCE: return 1.02;
case BELGIUM: return 1.15;
case DENMARK: return 1.10;
case NETHERLANDS: return 1.07;
case LUXEMBOURG: return 1.09;
case KANADA_HEALTH: return 1.00;
case KANADA_FOOD: return 1.05;
case KANADA_REPAIR: return 1.07;
case KANADA_SERVICE: return 1.11;
case KANADA_PRODUCTIVE: return 1.14;
}
}
}
Man braucht nicht zu erwähnen, dass der Programmierer den inzwischen unpassenden Variablen-Namen „countryTax“ in „CalculateBill“ so lässt. „taxVariation“ oder „taxType“ wäre nun besser, da es ja nicht mehr nur um das Land, sondern auch um die Dienstleistungsart geht. Würde der Programmierer den Code mit einem anderen Programmierer reviewen, also den Umbau/die Lösung im Detail noch einmal mit einem anderen Codierer sorgfältig besprechen, wäre diese Kleinigkeit vielleicht noch aufgefallen. Unser Programmierer verzichtet darauf, weil „das Feature ja grundsätzlich funktioniert und die letzte Änderung nicht so groß war“.
Das Beispiel zeigt sehr gut, dass alle Probleme zusammen dafür sorgen, dass sich Bugs hineinschleichen und dass Code an Qualität verliert. Deshalb sollte jeder Mitarbeiter sein Bestes geben und seine Arbeitsmoral nicht verlieren. Gleichzeitig muss man Prozesse in der Firma stets hinterfragen und optimieren. Was man letztlich durch eine schnelle Lösung an Zeit spart, kommt hinterher durch Mehraufwand zweifach wieder zurück. Das sieht man auch an diesem Beispiel: Der Programmierer musste mehrmals Hand anlegen, P.O. und Kunden-Betreuer mussten die Funktionalität mehrmals verifizieren, der Kunde wurde belästigt, es werden mehrere (!) Programmierer den Polen-Bug und den Bug/die Bugs mit den verschobenen Faktoren lösen müssen und der nächste Codierer, der die Funktionalität erweitert, muss den Code zunächst auf weitere Kategorien umbauen bevor er richtig beginnen kann (und wenn er etwas kaputt macht, gibt es wieder keinen Test der darauf hinweist). Eine „Lose-Lose-Situation“.
]]>
Welche Sprachen sprechen Sie? Natürlich Deutsch, wahrscheinlich Englisch, vielleicht auch ein wenig Spanisch und ein paar Wörter Französisch. Ich spreche Java, VHDL, HTML, kannte auch früher etwas VB – da bin ich aber total aus der Übung – und ein paar Brocken CSS. Gerade lerne ich TypeScript, aber mehr so als Hobby. Programmiersprachen sind ein Thema, das viele verschiedene Facetten besitzt und für Außenstehende sehr undurchsichtig ist. Trotzdem haben sie eine große Bedeutung für die Arbeit der Programmierer. In diesem Artikel erfahren Sie alles über Programmiersprachen, was Sie wissen sollten.
Wozu gibt es Programmiersprachen?
Das, was der Computer eigentlich an Befehlen verarbeiten kann, ist sehr schwer lesbar und kaum verständlich. Deswegen verwenden die Codierer ein Hilfskonstrukt: die Programmiersprache. Sie liefert eine Grammatik (Syntax), in der man seine Software-Beschreibung verfassen kann. Weil durch die Regeln dieser Sprache die Befehle eindeutig werden, kann man sie später auch für den Rechner übersetzen. Der Vorteil ist, dass man den Code sehr viel leichter lesen, verstehen und verfassen kann, als es bei den primitiven Computerbefehlen der Fall ist. Dadurch kann man die Software-Mechanismen leichter begreifen, Algorithmen schneller verfassen, Fehler leichter finden, mit anderen besser über den Code reden und sogar teilweise Dinge im Programm analog zu real existierenden Gegenständen und Konzepten benennen. Der Nachteil ist, dass man weniger Kontrolle über die tatsächliche Ausführung hat. Man ist deshalb angewiesen auf die Performance-Optimierungen der im Hintergrund arbeitenden Werkzeuge. Manchmal ist es dadurch auch schwer nachzuvollziehen, warum sich der Computer gerade auf eine bestimmte Art und Weise verhält. Insgesamt überwiegen aber die Vorteile massiv.
Muss man Programmiersprachen wirklich lernen?
Leider ja. Programmiersprachen nähern sich zwar immer mehr unserer natürlichen Sprache an, aber sie haben noch längst nicht das gleiche Niveau erreicht. Trotzdem gibt es einen kleinen Trost: Wer schon eine Sprache kann, der kann ähnliche Sprachen sehr leicht dazulernen, denn das Schwierige sind nicht unbedingt die Regeln an sich, sondern das gesamte Konzept.
Es gibt jedoch einige Bestandteile, die man sich einprägen muss. Dazu gehören
- Schlüsselwörter/Keywords: Das sind Wörter, die im Code etwas bestimmtes markieren oder auslösen.
- Sonderzeichen: Ähnlich wie Schlüsselwörter können auch bestimmte Zeichen für eine Aufgabe im Code reserviert sein.
- Platzierung von Informationen im Text: Manchmal muss man darauf achten, wo man etwas im Text platziert, weil der Computer bestimmte Dinge an festen Stellen im Text sucht.
- Aufbau aus mehreren Texten: Damit man die Übersicht behalten kann und das Programm strukturiert ist, muss man Abschnitte des Codes über mehrere Texte verteilen. Hier muss darauf geachtet werden, welche Teile voneinander wissen sollen.
- Verhalten der Ausführung: Als Coder muss man sich genau vorstellen können, welche Teile des Codes wann ausgeführt werden. Dazu gehört auch das Wissen über Gleichzeitigkeit, Reihenfolgen und das temporäre Sperren von Bereichen.
- Konventionen: Das sind Regeln in der Formatierung des Codes, die zwar keine Pflicht sind, aber sehr nachdrückliche Empfehlungen. Man sollte sie kennen, denn sie erleichtern einem Team das gemeinsame Arbeiten an einer Software.
Die Sprache erlaubt es mir, Mist zu bauen…
Eine Programmiersprache lässt dem Codierer jedoch auch gewisse Freiheiten. Dazu gehören nicht nur die Reihenfolge der Befehle und die Auswahl der Eingaben, sondern auch frei wählbare Namen. Man kann zum Beispiel Code-Abschnitte benennen, um sie später besser finden zu können und um zu wissen, was sie machen, ohne sie genau anschauen zu müssen. Auch gerade gehaltene Daten kann man mit Namen versehen. Dadurch fällt es leichter zu verstehen, was die Befehle machen.
Ein Beispiel: Ich möchte im Code zwei Zahlen nach dem Komma abrunden und dann addieren. Ohne frei wählbare Namen sähe das beispielsweise so aus:
int z = Math.round(x) + Math.round(y);
Mit frei wählbaren Namen erhält man hingegen:
int summe = rundeAbUndAddiere(ersterSummand, zweiterSummand);
Auch der untere Code ist für Laien noch nicht so leicht zu verstehen, aber immerhin kann man sich denken, was in etwa passiert. Das große Problem ist, dass viele mit dieser Freiheit nicht umzugehen wissen. Schlechte Programmierer können Namen wählen, die missverständlich, komplett unverständlich oder schlicht falsch sind. Für obiges Beispiel wären sehr schlechte Namen:
int s = raua(x, y); int xyz = roundDownUndAdd(bla, blub); int zahl = addiere(one, two);
Komische Abkürzungen, ein Mischmasch aus Deutsch und Englisch oder einfach falsche Bezeichnungen („addiere“ ist nicht das, was der Code macht – er rundet ab und addiert) führen leider immer wieder dazu, dass man Fehler nicht findet, neue Probleme erzeugt und ewig braucht, um Code zu verstehen. Der Programmierer ist als Autor jedoch verantwortlich, dass der Text nicht nur korrekt ausgeführt wird, sondern auch von anderen Codierern verstanden werden kann. Das ist sehr wichtig, um als Team gleichzeitig an einer Software zu arbeiten, um selber Fehler zu erkennen und um seinen eigenen Code noch nach einem Jahr verstehen zu können.
Wie haben sich Programmiersprachen im Laufe der Zeit entwickelt?
Die ersten Computer waren eben nur das: Computer, also Rechner. Sie konnten nur mehr oder weniger primitive Berechnungen durchführen wie „addiere 1 zu 3“ oder „gibt mir die Quadratwurzel zu 16“. Solche Berechnungen hat man miteinander verkettet und so komplexere Aufgaben erledigt. Der Code dazu sah in etwa so aus:
45 4c ea 81 02 d0 42 00 00 00
oder so
10001010100110011101010100000010000001011011000010000000000000000000000000
Nun. Das ist Maschinensprache. Das sind die Befehle, die ein Prozessor verarbeitet. Man spricht hier von einer Programmiersprache der ersten Generation. Weil man damit kaum arbeiten kann führte man das hier ein:
ADDI #1, #3, r37 SQRT #16, r74
Das ist Assembler, eine Sprache der zweiten Generation. Man ersetzte die Zahlen durch Kürzel und Symbole. Die Befehle blieben jedoch so primitiv wie in der Maschinensprache. Früher, so in den 50er und 60er Jahren, war die Auswahl der Befehle noch ziemlich eingeschränkt. Alle Möglichkeiten für einen Befehl haben auf eine Lochkarte im halben DIN-A5-Format gepasst. Dort hat man mit einer speziellen Schreibmaschine die Löcher ausgestanzt, sodass der Rechner mit einer Stiftleiste die Karte einlesen konnte. Ein Koffer voller Karten war dann ein Programm.
Teilweise programmiert man heutige Mikrocontroller noch immer in Assembler. Allerdings werden die Daten jetzt natürlich digital vorgehalten und es gibt sehr viel mehr Arten von Befehlen – auch welche, die sehr viele Aufgaben auf einmal erledigen.
1 + 3 SQRT(16)
Mit „FORTRAN“ wurde Ende der 50er Jahre die erste Höhere Programmiersprache veröffentlicht. Sie bot dem Codierer schon sehr viel bis dato unbekannten Komfort. Zum Beispiel konnte man bestimmten Abschnitten und Variablen Namen geben, was in Assembler ja überhaupt nicht möglich war. Darüber hinaus fügte man auch noch weiteren Komfort hinzu, etwa die automatische Zuweisung von Speicherzellen. So muss sich der Programmierer keine Gedanken mehr darüber machen, in welcher Zelle welche Daten liegen – er benutzt einfach die Namen der Daten.
Die dritte Generation war geboren. Viele der heutigen Sprachen entsprechen formell auch dieser Stufe, zum Beispiel „C++“ und „Java“.
Damit man sich der menschlichen Sprache immer mehr annähert, hat man auch hier nicht Halt gemacht:
SELECT birthday FROM employee WHERE lastname IS "Dinkelhuber"
SQL ist ein Beispiel für die vierte Generation. Der Code hier liest sich eigentlich schon wie ein englischer Satz. Zwar gibt es immer noch Beschränkungen in der Formulierung („SELECT – FROM – WHERE“ muss in dieser Reihenfolge mit diesen Schlüsselwörtern verwendet werden und „birthday“ und „lastname“ müssen als Spalten in der Tabelle „employee“ vorhanden sein), aber ich würde behaupten, dass auch ein Laie weiß, was der Code macht. Das Besondere ist aber, dass man keinen algorithmischen Ansatz mehr hat, also keine Berechnung mehr beschreibt, sondern einfach bestimmte Informationen anfragt und die Eigenschaften der benötigten Informationen beschreibt.
Die fünfte Generation der Programmiersprachen möchte ganz abstrakt logische Probleme lösen. Das ganze geht schon sehr in Richtung Künstliche Intelligenz. Ich gebe in den Computer ein, wer wessen Elternteil ist, ich definiere für den Computer, was Großeltern sind und dann kann ich ihm die Frage stellen, wer wessen Großelternteil ist:
parent ( ’ Elizabeth ’ , ’ Queen Mum ’) . parent ( ’ Elizabeth ’ , ’ George ’) . parent ( ’ Charles ’ , ’ Elizabeth ’) . parent ( ’ William ’ , ’ Charles ’) . grandparent (X , Z ) : - parent (X , Y ) , parent (Y , Z ) .
? - grandparent (X , Y ) . X = ’ Charles ’ , Y = ’ Queen Mum ’ ; X = ’ Charles ’ , Y = ’ George ’ ; X = ’ William ’ , Y = ’ Elizabeth ’.
Das hier ist „Prolog“. Die Programmierung erfolgt über Bekanntgabe von Fakten und die Definition von Konzepten. Würde ich alle Fakten und Konzepte der Welt ganz stumpf eingeben, dann könnte ich dem Computer die Frage stellen „Was ist das nahrhafteste Gericht, das ich mit den Resten aus meinem Kühlschrank kochen kann?“ und würde einfach so die richtige Antwort erhalten. Eine aktuelle Anwendung ist beispielsweise die Abfrage einer Bahn-Verbindung für eine bestimmte Strecke.
Man beachte: Derzeit (anno 2018) schreiben wir kommerzielle Software in Sprachen der dritten Generation mit Einstreuungen der vierten Generation (z.B. Java + SQL).
Welche Arten von Programmiersprachen gibt es?
Es gibt unzählige Arten von Programmiersprachen und in jeder Kategorie wiederum unzählige Beispiele. Wichtig ist es eigentlich nur zu verstehen, dass es für jede Aufgabe eine eigene Kategorie an spezialisierten Sprachen gibt. Trotzdem möchte ich Ihnen ein paar Beispiele nennen:
- Aufbau von grafischen Oberflächen und Anzeigen (CSS, Angular…)
- Beschreibung von Algorithmen und Datenverarbeitung (Java, C++, C#, .NET…)
- Beschreibung von Datenstrukturen (HTML, XML…)
- Konfiguration und Abfrage von Datenbanken (SQL…)
- Beschreibung von mathematischen Funktionen, ihre Berechnung und die Anzeige von Graphen (Matlab, Octave, Mathematica…)
- Berechnen von Statistiken und ihre Darstellung (R…)
- Beschreibung von Hardware-Komponenten und Test auf ihre logische Korrektheit (VHDL, Verilog…)
Oft kann man mathematisch beweisen, dass all diese Sprachen exakt genau gleich viel können (Turing-Vollständigkeit). Trotzdem entwickelt man Programmiersprachen, die an ihren Einsatzzweck angepasst sind, sodass man wesentlich gemütlicher Arbeiten kann.
Ein weiterer Bereich sind sogenannte „Esoterische Programmiersprachen“. Es gibt sie aus Spaß, zum Experimentieren oder um Rekorde aufzustellen. Besonders beliebte Vertreter sind „Brainfuck“ und „Shakespeare“.
Wie können Programmiersprachen helfen, besser mit Codierern zu kommunizieren?
Das war ein langer Artikel, oder? Falls Sie einfach nur zum Finale gescrollt haben: ich kann es verstehen. Falls nicht: Gratulation, Sie wissen jetzt für einen Nicht-Programmierer sehr viel über Programmiersprachen und können auf der nächsten Firmenfeier den Respekt der Nerds gewinnen!
Aber was können Sie aus diesem Text mitnehmen? Codierer sprechen oft ähnlich wie die Programmiersprache, die sie einsetzen. Vielleicht haben Sie auch schon Sätze gehört wie
„Ach, da fliegt wieder eine EXCEPTION.“
oder
„Das Feature wäre für mich nur, den ELSE-Teil der IF-Abfrage zu entfernen.“
Bitte nehmen Sie ihnen das nicht übel. Sie sind mit dem Kopf einfach voll und ganz im Programm und haben den totalen Tunnelblick. Das kommt daher, weil man sich sehr konzentrieren und viel Cognitive Load aufbauen muss, um überhaupt etwas über den Code sagen zu können. Vielleicht würde es helfen, wenn Sie sich eine Liste mit Schlüsselwörtern der verwendeten Programmiersprache bereitlegen. Dadurch würden Sie die Aussagen zumindest ein wenig besser verstehen. Weisen Sie den Programmierer aber deutlich darauf hin, wenn er sich Ihnen gegenüber zu fachlich ausdrückt! Es ist nämlich seine Aufgabe, Dinge in normale Sprache für Sie und andere Kollegen zu übersetzen.
Quellen:
]]>
Das Wort „Code“ klingt für viele ein wenig mysteriös. Liebespaare haben Codes für ihre Geheimnisse, in das Versteck der Mafia kommt man nur, wenn man den vereinbarten Code kennt und mit dem richtigen Code öffnet man den Safe, in welchem die Millionen schlummern. Wir wollen in diesem Artikel das Geheimnis des Codes ein für alle mal lüften!
Code ersetzt immer etwas
Schauen wir uns zunächst an, was das Wort „Code“ überhaupt bedeutet. Ganz allgemein gesprochen, ist ein Code immer ein Ersatz-Ausdruck für etwas anderes. Das oben genannte Liebespaar könnte vereinbaren, dass das einfache Zwinkern mit dem rechten Auge „Ich liebe dich!“ heißt. Schon hat man einen Code. Indem man die Vereinbarung nur mit denen Teilt, die den Code wieder decodieren können sollen, sorgt man für „geheimen“ Code. Dabei kann Code beliebig kompliziert sein. Einmal Zwinkern, das kann man sich leicht merken, aber wenn man viel mehr Ausdrucksmöglichkeiten haben möchte, dann muss man schon mit dem rechten und linken Auge Buchstaben morsen. Mit dem Morse-Alphabet kann man jeden Satz so codieren, dass er korrekt decodiert und somit verstanden werden kann. Merken Sie etwas? Wir sind schon mitten im Thema Informationsverarbeitung!
Welche Gründe gibt es für Codierung?
Es gibt viele Gründe, warum man Daten bzw. Informationen codieren sollte. Aus obigem Beispiel kennen wir schon die Geheimhaltung. Das Ceasar-Verschlüsselungsverfahren ist ein weiteres Beispiel. Hier wird ein Buchstabe mit einem – sagen wir – im Alphabet drei Plätze hinteren ersetzt. Aus „Adam“ wird „Dgdp“. Das ist bereits ganz simple Kryptographie.
Manchmal möchte man aber einfach nur Informationen in eine andere Form umwandeln. Indem man beispielsweise einen Text digitalisiert, kann man ihn ganz leicht auf einem USB-Stick speichern, per E-Mail verschicken und zur Datensicherung vervielfältigen. Aus „Adam“ wird dann „1000001 0010011 1000011 1011011“ (man merkt, wenn man weniger Zeichen zur Codierung hat, wird der entstehende Code länger).
Vielleicht möchte ich aber auch meine Dateien verkleinern, sprich komprimieren. Ich lege einfach mal fest, dass a=1, d=00 und m=01 sind. Wenn ich diese Regel in meinem Komprimierungs- und Dekomprimierungsprogramm hinterlege, wird aus „1000001 0010011 1000011 1011011“ nun „100101“ – viel kürzer! Natürlich kann mein Textprogramm „100101“ nicht lesen, weshalb ich den Text vor dem Öffnen wieder zurück codieren muss. Man sieht: Kein Vorteil ohne Nachteil.
Ein weiterer Grund für Codierung ist Vereinheitlichung. Ein Jurist würde den Fall des Nachbarschaftsstreits derart durch Rechtssprache ersetzen, dass niemand – außer Anwälte und Richter – mehr versteht, worum es überhaupt geht. Wo manche nur Schikane vermuten, geht es eigentlich darum, das man die sehr ungenaue und missverständliche Alltagssprache so umformuliert, dass jeder Fach-Experte sofort ganz genau versteht, was Sache ist. Und jeder Experte versteht im juristischen Text auch haar genau das gleiche, ohne dass man viel erklären muss. Man kann sich also kurz fassen und es gibt keine Missverständnisse.
Was haben nun Codierung und Programmierung miteinander zu tun?
Das Blöde ist jetzt, dass Programm-Code oft als „Geheimhaltung“ empfunden wird. Vielleicht mag der ein oder andere sogar denken, dass sich Informatiker einfach nur unersetzlich machen möchten und es deshalb so kompliziert machen. Dabei kann eigentlich jeder ohne Probleme jede Programmiersprache kostenlos im Internet lernen.
Der eigentliche Grund für Programm-Codierung ist aber, dass man die Programm-Beschreibung einheitlich aufschreibt, damit der Computer ganz genau, aber auch wirklich exakt auf den Punkt, weiß, was er machen soll. Die Maschine ist in dem, was sie versteht, sehr eingeschränkt. Da gibt es Null Toleranz. Deshalb muss man sich an feste Regeln halten, die die Programmiersprache ausmachen. Man versucht zwar immer mehr, es dem Menschen einfacher zu machen, aber letztlich wird man sich der kalten, sachlichen Ausdrucksweise nicht entledigen können.
Irgendwann wird aber jeder aus seinen Gedanken eine Software machen können, oder?
Ein Computer braucht zum Erstellen eines Programms eine Beschreibung. Egal wie diese Beschreibung aussieht, der Codierer ist stets die Person, die dem Computer diese Beschreibung formuliert und mitteilt. Darum wird es wohl für immer Programmierer geben. Dieser Mensch ist in der Lage, solche Beschreibungen vollständig und strukturiert zu gestalten. Er erkennt mögliche Probleme und Definitionslücken. Außerdem kann er die Beschreibung so optimieren, dass der Computer damit besser zurecht kommt (z.B. dass er schneller ist), dass man Teile der Beschreibung leicht wiederverwenden kann und dass andere Menschen gut mit der Beschreibung klar kommen.
Wie Sie sehen sind diese Aufgaben komplett unabhängig davon, wie die Beschreibung letztlich aussieht. Sie könnte also auch in alltags-verständlicher deutscher Sprache verfasst sein. Trotzdem braucht es einen geschulten Coder, um zwischen Mensch und Maschine zu vermitteln.
Wie soll ich als Nicht-Programmierer mit Code umgehen?
Sie könnten damit anfangen, Programmiersprachen zu lernen. Kleiner Witz Niemand zwingt Sie dazu, die Arbeit des Codierers zu machen, wenn sie eigentlich gar keiner sind. Auf der anderen Seite sollten Sie besser Abstand von der Programmierung halten, wenn Sie kein Programmierer sind. Die Lehre des Codierens besitzt einige sehr komplexe Konzepte, die Sie womöglich noch nicht kennen und die selbst erfahrene Programmierer nicht immer auf Anhieb verstehen. Schlimmer als jemand, der sich nicht auskennt, ist jemand, der sich nicht auskennt, aber denkt, er könne schon alles. Es braucht nämlich Übung, Übung, Übung, um ein guter Programmierer zu werden und selbst dann ist das Lernen niemals zu Ende!
Als Außenstehender brauchen Sie über Code eigentlich nicht mehr zu wissen, als dass er sehr unflexibel und strikt arbeitet. Sie können hier helfen, indem sie dem Programmierer eine möglichst vollständige Beschreibung des Software-Verhaltens liefern. Dazu gehört die Abdeckung jedes erdenklichen Falles und auch, was das Programm nicht machen soll.
Sich ständig ändernde Vorgaben und Unwissen darüber, was man eigentlich möchte, sind genau das, was der Programmierer nicht braucht, ihm die Arbeit schwer macht und letztlich zu einen schlechten Produkt führt (hinter diesen Satz kann man eigentlich nicht genug Ausrufezeichen machen)!
Wenn Sie das alles jedoch beachten, dann werden Sie und der Codierer sich vielleicht auch eines Tages fröhlich zuzwinkern
Sehr viele Wege führen nach Rom und wer ein Programmierer werden möchte, der hat heute eine ganze Reihe von Möglichkeiten. Jede Option hat so ihre Vor- und Nachteile. In diesem Artikel soll es darum gehen, was einen bei der Ausbildung erwartet und was Arbeitgeber von den jeweiligen Absolventen erwarten können.
Bitte nicht Arbeit, Beruf und Ausbildung vermischen!
Zuerst einmal ist es wichtig, dass man die vielen unterschiedlichen Berufs-, Arbeits-, und Ausbildungsbezeichnungen nicht durcheinander wirft. „Programmierer“ als Abschluss gibt es so eigentlich nicht. Man wird eher ganz allgemein zum Informatiker ausgebildet, teils mit bestimmten Spezialisierungen. Das Codieren ist nur ein Bereich des Berufs und kann ganz unterschiedliche Ausprägungen haben. Außerdem hängen die finalen Fähigkeiten nicht immer streng von der Ausbildung ab, sondern können je nach Person variieren. Nur so ganz nebenbei: „Software-Entwickler“ ist in Deutschland derzeit keine geschützte Berufsbezeichnung
Der irgendwie andere Programmierer
Manchmal ist ein Programmierer nicht das, was man sich darunter vorgestellt hat. Er schreibt keine Software für einen PC oder für das Handy, sondern programmiert beispielsweise eine CNC-Fräse oder einen Industrieroboter. Auch das ist streng genommen „Programmieren“. Es ist die Eingabe von Befehlen in eine Maschine, sodass die Maschine diesen Code ausführt und daraufhin gezielt bestimmte vorher festgelegte Dinge tut. Deshalb ist es wichtig zunächst zu prüfen, welche Art von Programmierer man meint. Meist reicht dafür die Nennung der in der Firma (oder im Aufgabenbereich) verwendeten Programmiersprachen, denn jede Sprache ist für einen Bereich spezialisiert.
Der Quereinsteiger, ohne einschlägige Berufsausbildung
Weil sich Informatiker oft auch privat für das Thema interessieren, kommt es häufig vor, dass Menschen ganz nebenbei sehr viele Fähigkeiten in der Programmierung erlernen. Indem man täglich viele Stunden Freizeit in Code investiert, kann man durchaus zu einem sehr guten Programmierer werden, vor allem, weil es viel hochwertige Fachliteratur in Form von Büchern und aktuelle und detaillierte Informationen auf vielen Webseiten gibt. Oft kennen sich semiprofessionelle Codierer gut aus mit aktuellen Techniken und Prinzipien, wissen über Trends Bescheid, gehen jedoch eher pragmatisch an Probleme heran.
Quereinsteiger haben das Problem, dass sie sich erst beweisen müssen. Trotzdem gehen viele Arbeitgeber das Risiko ein – aus Mangel an Alternativen. Dafür hat man hier aber ein relativ geringes Einstiegsgehalt zu erwarten (relativ, da es für jemanden ohne Berufsausbildung immer noch ziemlich hoch ist). Mit zunehmenden Berufsjahren gleichen sich die Gehälter etwas an.
Der Fachinformatiker
Wer eine normale Berufsausbildung machen möchte, hat an der Stelle zwei Möglichkeiten: Fachinformatiker für Anwendungsentwicklung (Software) und Fachinformatiker für Systemintegration (Hardware und Netzwerke). Die Ausbildung dauert drei Jahre und findet in der Berufsschule und in einem Ausbildungsbetrieb statt, meist abwechselnd in Blöcken von mehreren Wochen. Der Vorteil gegenüber dem Quereinsteiger ist, dass der Fachinformatiker Wissen systematisch beigebracht bekommt und versucht wird, ihm von Anfang an die richtige Vorgehensweise beizubringen, sodass die Gefahr, dass er sich etwas Falsches aneignet geringer sein sollte. Wenn der Ausbildungsbetrieb jedoch selbst unprofessionell arbeitet, kann es dazu kommen, dass der Azubi genau diese Prinzipien später als normal ansehen wird. Dazu kommt, dass die Berufsschule nur eingeschränkte Möglichkeiten hat, Problemlösungs- und Transfer-Fähigkeiten beizubringen – es geht eher um das Auswendiglernen. Für reine Programmierarbeit ist das allerdings oft eine ausreichende Basis. Nach der Ausbildung bieten sich dem Fachinformatiker ein solides Gehalt und ganz gute Job-Chancen.
Der Informatiker (Fachhochschule)
Ebenso wie die Universität, hat die Fachhochschule ein Bachelor-Master-System. Für den Bachelor-Abschluss hat man eine Regelstudienzeit von drei Jahren (sechs Semestern) und für den Master noch weitere zwei Jahre (vier Semester). Man sollte beachten, dass der FH-Informatiker die Möglichkeit der Spezialisierung hat und in seinem Studium verschiedene Schwerpunkte wählen kann. Durch das Vollzeitstudium wird sehr viel Wissen vermittelt. Außerdem lernt der Student die Fertigkeiten zur Problemlösung und zum Problem-Transfer. Der wichtige Unterschied gegenüber der Universität ist, dass viel mehr Wert auf Praxis gelegt wird. Kooperationen mit Unternehmen und der freien Wirtschaft kommen häufig vor. Studenten, die an der verkopften Theorie der Universität scheitern, werden meist an der FH glücklich und erfolgreich. Gehalt und Job-Chancen sind exzellent. Im Job kann der FH-ler durch seine Praxiserfahrungen zügig eingesetzt werden und bringt bereits viele anwendbare Vorkenntnisse mit.
Der Informatiker (Universität)
Vieles, was für die FH gilt, gilt auch für die Universität: Bachelor für drei Jahre (halb Grundwissen, halb Spezialisierung) und Master für zwei Jahre (nur Spezialisierung). Es werden sehr viel Wissen und Problemlösungsfähigkeiten im Vollzeitstudium vermittelt. Allerdings wird wesentlich mehr Wert auf Theorie gelegt als bei der FH. Nur wer keine Angst vor extrem abgefahrenen mathematisch Denkaufgaben hat, sollte das Studium ins Auge nehmen. Der Absolvent ist schließlich in der Lage, sehr komplexe Probleme zu erfassen und aufzubereiten. Er erkennt Schwierigkeiten, die man anderen oft nur schwer erklären kann. Auf der anderen Seite kann er seine Skills durch eine Vielzahl von Vorlesungen weit streuen. Negativ ist, dass sich kaum Möglichkeiten ergeben, Praxiserfahrung in der Wirtschaft zu sammeln. Oft kommt es vor, dass der frische Absolvent gar keine Ahnung von der Arbeit in einer Firma hat. Man sollte also trotz des hohen Gehalts nicht davon ausgehen, dass der Informatiker sofort und direkt loslegen kann. Das alles macht der Akademiker durch extrem schnelles Lernen und super Abstraktionsfertigkeiten wett. Schon nach kurzer Zeit wird der Uni-Informatiker durch sein Allround-Können geschätzt werden und er weiß durch ungeahnte Fähigkeiten zu überraschen.
Man beachte: An der Universität gibt es viele verschiedene informatiklastige Studiengänge. Neben der „normalen“ Informatik gibt es natürlich noch die Lehrämter, die mit ihrem Didaktikanteil die Studienzeit verlängern. Außerdem stößt man immer wieder auf Spezialausrichtungen wie „Luft- und Raumfahrtinformatik“ (mit Abschluss Space-Master!). Wirtschaftsinformatik und Mediendidaktik haben jedoch einen erstaunlich geringen Anteil an Informatikfächern. Daneben gibt es noch spannende Studiengänge wie „Mensch-Computer-Interaktion“, was eine Mischung aus Informatik und Psychologie darstellt und „Bio-Informatik“ (mit Biologie-Teil).
Diplom und Doktor
Diplom-Studiengänge können heute eigentlich nirgends mehr begonnen werden. Der Diplomstudiengang unterscheidet sich dadurch von Bachelor-Master, dass das letztere System eher verschult ist und der Studienverlauf sehr viel genauer festgelegt ist. Ein Diplomand konnte sich im Studium mehr nach seinen eigenen Interessen ausrichten. Während er vor allem die Prüfungen „Vordiplom“ und „Diplom“ schreiben musste, muss der Bachelor bzw. Master für jede einzelne belegte Vorlesung am Ende des Semesters eine Klausur schreiben. Er jagt weniger dem Wissen, eher den Belegungspunkten hinterher.
Der Doktor der Informatik ist für viele Jobs überqualifiziert. Er kann eigentlich nur in der Hochschule und in der forschenden Wirtschaft sinnvoll eingesetzt werden. Sofern er aber keine hohen Gehaltsvorstellungen hat, kann er natürlich auch als gewöhnlicher Informatiker Fuß fassen.
Was ist nun die richtige Wahl?
Der Arbeitgeber hat meist keine große Auswahl und muss nehmen, was er kriegen kann. Das ist jedoch weiter nicht schlimm, denn in einem heterogenen Team findet sich für jeden eine sinnvolle Beschäftigung.
Wer Programmierer werden möchte, der muss schauen, wo seine Prioritäten liegen. Falls die Hochschulreife bereits vorliegt, sind FH und Uni interessant (Uni nur, wenn Mathe kein Problem ist oder man sehr fleißig ist). Wer keine Hochschulreife hat, der kann direkt mit der Ausbildung zum Fachinformatiker beginnen. Mit Engagement kann man es auch hier weit bringen.
Um eines vorweg zu nehmen: Natürlich ist jeder Programmierer anders. Wir sind schließlich auch alle nur Menschen und haben (hoffentlich) individuelle Interessen, Macken und Talente. Darum gibt es eben auch nicht den Programmierer als Schublade. Manche sind alt, manche jung, manche haben Frau und Kinder, mache sind sportlich, manche sind schwul, manche sind Frauen und manche mögen Pilzpfanne. Trotzdem kann man bestimmte Muster in der Selbstwahrnehmung ausmachen, die mal mehr mal weniger ernst gesehen werden. In diesem Artikel soll ein Blick in die Gilde der Coder geworfen werden.
Das Bild des Informatikers hat sich über die Jahre gewandelt
In der ersten Hälfte des 20. Jahrhunderts waren Programmierer vor allem Mathematiker, die mit Hilfe von Rechenmaschinen komplexe Berechnungen anstellen konnten. Nicht selten standen sie im Militärdienst und berechneten ballistische Flugbahnen für Raketen oder entschlüsselten geheime Nachrichten wie etwa Alan Turing, der dadurch auf britischer Seite den Zweiten Weltkrieg um Monate verkürzte.
Danach kam die Zeit der 50er, 60er und 70er Jahre, in denen der Programmierer meist ein Mann mittleren Alters in Nadelstreifen, rauchend und mit Aktenkoffer (für die Lochkarten) war. Er galt als Experte für die Bedienung der raumeinnehmenden Computer, die aufgrund ihrer Größe und Kosten eher dem großen Business vorbehalten waren. Anerkennung und Respekt waren ihm sicher.
Das änderte sich sehr mit dem Erscheinen der ersten Heim-Computer in den 70er und 80er Jahren. Gerade Jugendliche und Kinder kamen schnell mit der Abstraktion des Programmierens zurecht. Sie waren wissbegierig, trauten sich, Dinge auszuprobieren und die Grenzen zu erforschen. Es entstand schließlich das Bild des Kellerkindes, das sich in irgendwelche Banken hackt und aus Spaß Kriege startet.
Mit der steigenden Beliebtheit des Internets seit den 90er Jahren rückt auch der Beruf des Programmierers immer mehr in den Fokus und man verbindet mit dem Begriff „IT“ das große Geld und einen zukunftssicheren Job, der einen schicken Lifestyle ermöglicht.
Im Kopf blieben vor allem die Darstellungen aus Filmen
Hauptschuldige sind wohl eine ganze Reihe von Filmen aus den 80er und 90er Jahren, die „irgendetwas mit Hacken“ zum Thema hatten. Der Computer-Experte dort war meist ein ungepflegter, dicker, pickeliger Junge mit fahler Haut und der Unfähigkeit zum Führen sozialer Kontakte. Bevor es Laptops und Smartphones gab, blieb dem Interessierten damals natürlich nur der stationäre Rechner. Das heißt aber nicht, dass man keine Freunde hatte und immer nur im abgedunkelten Zimmer saß. Es war einfach die subjektive Wahrnehmung damaliger Erwachsener, die ihre Kinder nicht mehr verstanden (was vielleicht jeder Generation irgendwann einmal passiert). Fakt ist aber, dass sich die jungen Programmierer selber anders wahrnahmen und auch heute anders sehen.
Der Programmierer als Alltags-Zauberer
Die Bewunderung von Verwandten und Freunden, wenn man mal wieder das „Internet repariert“ oder jemandem zwei Wochen stupide Arbeit abgenommen hat, prägt den Informatiker. Ich habe während meiner Schulzeit jemandem das Abschreiben der Schulordnung erspart, indem wir seine Handschrift in ein Formular eintrugen, das dann einscannten, daraus automatisch eine Schriftart erzeugten und den heruntergeladenen Text in der gerade erzeugten künstlichen Handschrift ausdruckten. Der Lehrer merkte den Unterschied nicht.
Auch wenn die Tätigkeit manchmal leicht erscheint und schnell geht, sollte man die Leistung nicht unterschätzen. Das Wissen über Programmierung erlangt man nur mit viel Übung und jahrelangem Lernen. Viele Codierer haben nicht nur die Berufsschule, Universität oder Fachhochschule besucht, sondern vor allem in der Freizeit einiges an Lebensjahren investiert, um beim Programmieren besser zu werden. Ein Informatiker ist oft mehr als ein Vollzeit-Informatiker, er identifiziert sich rund um die Uhr mit seiner Berufung und erwartet daher einen gewissen Respekt. Beleidigt man ihn in als Programmierer, dann trifft es ihn ganzheitlich als Menschen, denn nach Feierabend setzt er sich regelmäßig auch zu Hause noch an Code – es ist sein Leben.
Programming on Weekends – It’s like programming during the week but pants are optional.
Ihn in seinen Fähigkeiten bloß zu stellen ist wie einem Gärtner zu sagen, dass er die Blumen zu Hause übergießt oder einem Arzt zu sagen, dass er keine Ahnung hat, was seinem kranken Kind gut tut. Und ja, das ist nicht übertrieben, denn die Software, die der Coder schreibt, ist sein Kind, sein Baby. Deshalb reagiert er manchmal auch so emotional.
Der Programmierer als Universalgenie
Ein Programmierer muss in der Lage sein, schnell zu verstehen und schnell zu lernen. Zum einen gibt es ständig Neuerungen und Fortschritte im Programmierwissen der Welt und Standards werden im Jahrestakt umgeschmissen. Was heute noch richtig war, kann morgen schon als absolut veraltet und überholt gelten. Hierin liegt der Grund, warum Programmierer ständig von „uraltem Legacy-Code“ sprechen, der sie zum verzweifeln bringt. Zum anderen weiß er während seiner Ausbildung oft nicht, wo er irgendwann einmal landen wird. Es könnte eine Druckerei sein, ein könnte eine Großgärtnerei sein, eine Softwarefirma, eine Klinik oder, oder, oder. Er muss sich also vielen Problemen öffnen können, die ganz und gar nicht zu seiner Berufsausbildung gehören. Deshalb ist der Programmierer extrem darauf angewiesen, dass alle seine Aufgaben sehr exakt aufbereitet werden, denn es gehört einfach nicht zu seinem Job, etwas über Pflanzen, Arzneimittel oder Papierstärken zu wissen.
Der Programmierer als Held der Arbeit
Die Arbeit eines Programmierers ist oft sehr demotivierend. Man steckt sein ganzes Herzblut in die Software, schreibt als Autor (ja, wir sind Autoren) non stop Funktionalität – nur um uns am Ende anzuhören, wie schlecht alles läuft, wie kacke die Performance ist und dass jeder einzelne Bug eigentlich Schmerzensgeld zur Folge haben müsste. Im Gegenzug wird ein absolut sauber laufendes Programm als „normal“ empfunden.
Zu diesem Druck kommt noch der Druck aus dem Vertrieb und dem Marketing. Die subjektive Wahrnehmung des Codierers ist, dass ich als Programmierer die Versprechen einhalten muss, die andere aussprechen. Selbstverständlich verzerrt es die Realität, denn ohne Verkäufe und neue Features kommt eben auch kein Geld in die Firma. Trotzdem müssen die zu erledigenden Aufgaben fair zwischen allen Beteiligen ausgehandelt werden. Der Programmierer darf kein Trichter sein, in den man alles reinkippt und wenn es zu langsam läuft, dann stopft man nach.
Außerdem denkt fast nur der Coder so richtig an Stabilität und Qualität der Software. Klar, jeder möchte ein qualitativ gutes Programm. Aber nicht viele sind bereit, Geld und Zeit darin zu investieren. Etwas, was man nicht sehen kann und etwas, was man im Programm nicht direkt bemerkt (Stichwort: Testabdeckung), kann man dem Rest der Firma leider nur schlecht vermitteln. Aber wie schon gesagt: Die Software, die ich selber schreibe, ist mein Baby. Ich will, dass es ihm gut geht.
Der Programmierer als Aktivist
Bei weitem nicht alle Programmierer würden sich als Aktivisten bezeichnen. Trotzdem gibt es ziemlich viele Informatiker, die sich mit Rechten, Freiheiten und Verantwortungen auseinander setzen. Diese Leute sind oft politisch links-liberal. Ihre Sicht der Dinge ist, dass die Technik mehr Chancen und Risiken aufwirft, als die meisten Menschen verstehen (können). Sie missionieren regelrecht, um immer wieder ihren Standpunkt klar zu machen: Basis-Demokratie soll über staatlicher Kontrolle stehen und alle Menschen müssen begreifen, was ihre Daten wert sind und welche Gefahren des Datenmissbrauchs lauern. Sie möchten 1984 verhindern und haben das Gefühl, dass die Welt sehenden Auges ins offene Messer rennt. Diese Informatiker sind Fatalisten, die die Mantren „Mach Backups!“ und „Verschlüssle deine Mails!“ regelmäßig zum Besten geben. Ob sie Recht haben oder nicht, soll an der Stelle gar nicht diskutiert werden. Wichtig ist nur, dass sie sich als moderne Aufklärer betrachten und als Wahrer von ethischen Rechten.
Wie gehe ich nun mit dem Programmierer um?
Das alles hier soll bitte nicht so heiß gegessen wie gekocht werden. Die Wahrheit ist selbstverständlich relativ und nicht jeder Programmierer erfüllt komplett obige Eigenschaften. Zum einen sollte er natürlich den Respekt erhalten, der jedem Menschen grundsätzlich zusteht. Und er ist auch nicht unfehlbar oder ein Gott – obwohl manche auch auch an Selbstüberschätzung leiden. Man sollte nur beachten, dass eigentlich niemand Programmierer von Beruf ist, sondern man Programmierer ist, als ganzheitliche Person. Ein Codierer weiß Dinge und kann Sachen machen, die andere nicht einmal erahnen können. Wenn er aus seiner Fach-Sicht spricht, dann sollte man ihm zunächst einmal Glauben schenken, denn er ist der Experte in seinem Gebiet. Ausreden sind vielleicht keine Ausreden, sondern harte Realität. Und wenn man auf sachlicher und vernünftiger Ebene miteinander umgeht und diskutiert, dann wird man es auch schaffen, sich mit dem Programmierer auf eine ausgewogene Aufgabenverteilung zu einigen. Dafür muss man allerdings begreifen, dass auch der Programmierer mit einem ToDo-Stapel in die Verhandlung treten wird – und darf!
]]>
Wirklich sehr vielen Leuten fällt es schwer, mit Programmierern zu sprechen. Glauben Sie mir, damit stehen Sie nicht alleine da! Missverständnisse sorgen oft für Frust und gegenseitige Beschuldigungen. Dadurch laufen Projekte schlecht und die Stimmung im Team ist vergiftet. Es scheint fast so, als würde man in unterschiedlichen Welten leben und unterschiedliche Realitäten wahrnehmen. Aber woher kommt das? Sprechen wir nicht alle Deutsch (bzw. Englisch)? Und wer missversteht eigentlich wen?
Sprache ist ein Werkzeug
Fakt ist, Software-Entwickler und Manager sprechen nicht die gleiche Sprache. Genau genommen sprechen wir alle kein normales Deutsch. Jeder Beruf bringt es mit sich, dass sich auch eine fachspezifische Ausdrucksweise entwickelt. Vertrieb und Marketing beispielsweise besitzen ihre Buzzwords und versuchen, selbstbewusst Wertigkeit und Emotionen zu erzeugen. Sie müssen ein Produkt verkaufen und brauchen dazu dehnbare Formulierungen, die oftmals Auslegungssache sind. Sprachlich sind sie sehr durchsetzungsfähig. Das alles ist nicht als Vorwurf gemeint, es gehört einfach zum Beruf dazu. Projektleiter hingegen brauchen Einfühlungsvermögen, denn sie müssen es allen Recht machen. Ihre Aufgabe ist es, die Wahrheit sachlich, aber so gut es geht zu verpacken – gegenüber Entwicklern, Testern, Vertrieb, Kunden und der Firmenleitung. Wichtig hierbei ist es, Perspektiven aufzuzeigen und das Team zu motivieren. Trotzdem müssen auch sie sich durchsetzen können und den Eindruck erzeugen, zu wissen wohin die Reise geht.
Der Programmierer spricht nicht, er sagt ein Skript auf
Auch der Informatiker hat so seine eigene Sprache. Der wichtige Unterschied ist aber, dass er mit Maschinen reden muss, nicht mit Leuten. Während zwischenmenschliche Kommunikation heutzutage wie selbstverständlich zur Ausbildung von Projekt-Managern, Verkäufern, Marketing, Supportlern und Personalern gehört, ist das beim Programmierer ganz und gar nicht der Fall. Sein Beruf ist offiziell darauf beschränkt, seine Gedanken nur Computern klar zu machen. Natürlich witzelt man, dass der Informatiker selber wie eine Maschine redet und keine Emotionen kennt, allerdings steckt nun einmal ein Körnchen Wahrheit darin. Man sollte es dem Programmierer jedoch auch nicht zum Vorwurf machen, denn er steckt einfach zu sehr drin – und das ist auch gut so! Programmierer bzw. Informatiker wird man nicht von Heute auf Morgen. Man muss sich jahrelang mit der Materie auseinander setzen. Viele fangen sogar schon in ihrer Kindheit an, zu coden. Dadurch verinnerlicht man Formulierungen der Programmiersprache. Es ist eben auch wichtig, dass man diese Form des Ausdrucks sauber und strikt beherrscht, denn eine Maschine versteht nun einmal keine Ironie, keinen Sarkasmus und keine freie Auslegung. Der Computer sagt nicht „Hm, das meint er sicher nicht ganz so wie er es schreibt. Ich mache das mal anders.“. Gerade beim Programmieren ist es entscheidend, dass der Rechner eins-zu-eins das macht, was man ihm hinwirft. Der Codierer braucht die volle Kontrolle und der Computer muss verlässlich sein. Mit der Zeit lernt der Software-Entwickler als Mensch die Vorteile des Codes als Alltagssprache kennen: Sie ist eindeutig und gerade deswegen eigentlich resistent gegen Missverständnisse. Außerdem kann man sich sehr kurz fassen und trotzdem viel sagen – das spart Zeit und Atem!
Wie ist denn jetzt die Sprache der Programmierer?
Die Informatik ist ein Teilbereich der Mathematik. Moment, bitte nicht abschalten, es wird nicht so trocken, versprochen! Der Kern besteht also nicht aus der Technik wie Prozessoren, Festplatten und Strom und so weiter, sondern aus der Daten- und Informationsverarbeitung. Für viele scheint sehr gewöhnungsbedürftig zu sein, dass der Informatiker theoretisch auch mit Stift und Papier arbeiten könnte. Darum ist er auch nicht der „Computer-Fritze“, sondern der „Daten-Fritze“. Der Rechner (Ha, da ist wieder so ein mathematisches Wort!) ist einfach nur ein Mittel zum Zweck – ein Werkzeug. Dieses Werkzeug rechnet die Aufgaben des Informatikers einfach nur sehr viel schneller als er es selber könnte. Die Datenverarbeitung geschieht dabei selten mit der Mathematik, die wir aus der Schule kennen (Stichwort „4x – 2y = 14“), sondern eher mit Hilfe der Logik, einem anderen Teilbereich der Mathematik. Jetzt werden Sie vielleicht denken, dass Logik nichts exotisches ist und sie eigentlich jeder beherrscht. Lassen Sie sich gesagt sein, dass Logik eine eigene Vorlesung im Informatik-Studium ist und genug Unterrichtsstoff mit sich bringt. So einfach ist das alles nämlich nicht und wer denkt, etwas über Logik zu wissen, wird gleich eines Besseren belehrt!
Beispiele aus der Logik
Es gibt natürlich auch in der Logik sehr viele Unterteilungen, aber ich will Sie lieber damit verschonen. Belassen wir es bei einfachen, jedoch nicht minder beeindruckenden Beispielen.
Was ist das Gegenteil von „groß“?
„Klein“ wäre hier die falsche Antwort. Der Logiker würde selbstverständlich antworten „Nicht groß“. Immer, wenn man das Gegenteil von etwas möchte, macht man ein „nicht“ davor. Und wenn man etwas darüber nachdenkt, dann ist es… logisch. Denn ein Mensch kann zum Beispiel weder groß noch klein sein, sondern so mittel. Wenn er also „nicht groß“ ist, bedeutet es nicht gleich, dass er „klein“ ist.
Welche gegenteilige Aussage kann man aus „Es hat geregnet, also ist die Straße nass.“ ableiten?
Jetzt wird es schon etwas knackiger: Implikationen. Gerade beim Programmieren haben wir oft Wann-Dann-Formulierungen. „Wenn eine Datei im Ordner ist, dann soll sie geöffnet werden.“ Schauen wir uns mal obige Implikation an. Die gegenteilige Aussage lautet jedoch nicht „Es hat nicht geregnet, also ist die Straße ist nicht nass.“ Na klar, denn wenn ich mit dem Gartenschlauch hantiere, wird die Straße trotzdem nass – logisch. Man muss die Satzteile noch zusätzlich umstellen und verneinen: „Wenn die Straße nicht nass ist, dann hat es also nicht geregnet.“ Jetzt wird ein Schuh draus!
Wenn der Kunde anruft, dann hilf ihm bitte!
Ihr Programmierer wird dem Kunden nicht mehr als einmal helfen. Warum? Nun, er hat Ihren Wunsch erfüllt. Versuchen wir es noch einmal:
Immer wenn der Kunde anruft, dann hilfst du ihm!
Jetzt lässt sich der Programmierer ewig Zeit. Solange er irgendwann hilft, erfüllt er immer noch Ihren Wunsch. Der Befehl muss noch genauer werden:
Immer wenn der Kunde bei dir anruft, dann hilfst du ihm sofort bei seinem Problem!
Ok, wir haben dazugelernt. Wir haben gleich eine viel präzisere Formulierung verwendet. Aber was müssen wir da mit ansehen? Unser Programmierer ruft auch unaufgefordert beim Kunden an, auch wenn dieser keine Probleme hat. Warum? Das haben wir ihm doch gar nicht so gesagt! Tja, genau da liegt der Hase mit dem roten Punkt im Pfeffer oder so. Sie haben eine Option völlig frei gelassen und dem Programmierer damit unerwünschten Spielraum gegeben. Wo andere Menschen zwischen den Zeilen lesen, bleibt der Codierer stets auf dieser. Es gibt aber eine Lösung dafür:
Genau dann, wenn der Kunde bei dir anruft, hilfst du ihm sofort bei seinem Problem.
Ich hoffe, dass dadurch deutlich wird, wie ungenau unsere Alltagssprache eigentlich ist. Es ist – aus der Sicht des Informatikers – ein Wunder, dass wir mit der normalen Sprache überhaupt so gut kommunizieren können. Ein weiteres gutes Beispiel ist das kleine Wort „oder“.
Möchtest du Schoko- oder Vanille-Eis?
Ein Programmierer, der es darauf anlegt, wird Ihnen mit „Ja!“ antworten. In der Logik bedeutet „oder“ stets „und/oder“ (auf Englisch „or“). Wenn er also Schokoeis, Vanilleeis oder sogar beides möchte, dann ist die Aussage erfüllt, der Programmierer kann mit „ja“ bzw. „wahr“ (auf Englisch „true“) antworten. Möchten Sie ihn vor die Wahl stellen, dann brauchen Sie ein „entweder/oder“ (auf Englisch „exclusive or“, kurz „xor“). Sie müssen also fragen:
Möchtest du entweder Schoko- oder Vanille-Eis?
Und wenn der Programmierer mit „Ja!“ antwortet muss eine zweite Frage hinterher:
Möchtest du Schoko-Eis?
Wenn jetzt ein „Ja!“ kommt, dann ist die Sache klar. Falls ein „Nein!“ kommt, dann muss er ein Vanilleeis haben wollen, weil er ja genau eine der beiden Sorten möchte und wenn es nicht Schokolade ist…
Was kann ich jetzt machen, damit der Programmierer mich besser versteht?
Bestimmt werden Sie nicht auf die Schnelle lernen, so richtig logisch zu sprechen. Das bedarf leider viel Übung und Erfahrung. Versuchen Sie für den Anfang genau zu spezifizieren, was sie wollen. Sie können auch mit – aus Ihren Augen – übertrieben genauen Formulierungen arbeiten, das ist besser als nichts. Wichtig ist, dass sie auch ganz genau erklären, was Sie nicht möchten. Keine auch nur so kleine Möglichkeit soll unberücksichtigt bleiben und kein Bereich des Themas darf verborgen oder undefiniert sein. Erinnern Sie sich daran wie kleine Kinder sprachliche Spitzfindigkeiten für sich nutzen, um Erwachsene zu ärgern. Bei Codierern ist das hingegen nicht als Provokation gemeint, sondern schlichtweg Hilflosigkeit, weil Ihr Wille unklar ist. Der Programmierer interpretiert nämlich nicht, sondern sieht einfach nur die Fülle an Möglichkeiten und ist überfordert, weil er nicht weiß, welchen Weg er gehen soll. Mit der Zeit werden Sie sich bestimmt an das Formulieren sauberer Sätze gewöhnen – na logisch!
]]>