Programmierer

1. Programmierer

Programmierer sind (trotz anders lautender Gerüchte) Menschen, die zu nachtschlafender Zeit mit völlig untauglichen Entwicklungspaketen für nicht zusammenpassende Konglomerate fehlerverseuchter Hardware versuchen, im Auftrag von unfähigen Anwendern deren einander widersprechende Anforderungen in Programmen umzusetzen, die am Schluss niemand verwendet.

Programmierer zerfallen in zwei Kategorien. Die eine Sorte versagt bei dem Versuch, für viel zu wenig Geld mit viel zu viel Aufwand die logischen Irrtümer von Programmiersprachen, die Fehler von Compilern und die in Silizium gegossenen Ungereimtheiten der Hardware so gegeneinander auszuspielen, dass das Computersystem am Schluss wenigstens hin und wieder das tut, was man von ihm erwartet. Die andere Sorte tut dieses ganz umsonst. Beide tun es vergebens.

Generell ist das Denken eines Programmierers

logisch: IF 1=2 CALL Mainprogramm
strukturiert: ON Hunger CALL Pizza.de ELSE RETURN
und von keinerlei Vorurteilen beeinträchtigt. Obwohl es einzelne Vertreter dieses Berufszweiges geben soll, die dem Vorurteil aufsitzen, dass ein Computer dazu geschaffen wurde, dem Menschen zu dienen. Anstatt umgekehrt.

Oder, wie es der berühmte angloamerikanische Schriftsteller Wilhelm D. Base Shakespeare sagte: 2b.OR.NOT.2b.

Es ist zwar schwierig, Murphys Computergesetz aus Sicht des Programmierers zu schildern (schliesslich ist ein Programmierer das im Grunde völlig überflüssige Glied der Kette Marketingabteilung-Werbeabteilung-Programmierer-Vertriebsabteilung-Anwender-Reklamationsabteilung-Updateabteilung), aber auf den folgenden Seiten soll der Versuch dazu unternommen werden. Auch wenn sich Softwarehäuser und Anwender seit Jahren darüber einig sind, dass ihr Leben ohne die überbezahlten Programmierer und deren Einwände über die Machbarkeit bestimmter Programmanforderungen sehr viel leichter wäre.

Namhafte Hersteller sind deswegen mit wachsendem Erfolg seit geraumer Zeit dazu übergegangen, ihre Software mittels "CASE" (Computer Aided Software Engineering) direkt entwickeln zu lassen, weil letztendlich nur ein Computer Programme so schreiben kann, dass andere Computer sie auch in der richtigen Art missverstehen können.

Lükes Grundlage der Programmierung:
Es wird nicht funktionieren.

Erste Ableitung:
Funktioniert es doch, dann hat es jemand anderes geschrieben.

Zweite Ableitung:
Fluchen ist die einzige Sprache, die alle Programmierer fliessend sprechen.

Schlussfolgerung:
Ein Computer wird das tun, was du programmierst - nicht das, was du willst.

Das Machrone-Statement:
Wenn du es entwickeln kannst, ist es überholt.

Die Konkretisierung des Machrone-Statements:
Erst wenn du dein Programm fertig entwickelt hast und deine letzten Kredite in den Entwurf von Anzeigen und Werbematerialien gesteckt hast, wirst du feststellen, dass Microsoft ein gleichartiges Programm auf den Markt werfen wird.

Verallgemeinerung des Machrone-Statements:
Egal wie gross und standardisiert ein Marktsegment ist, Microsoft kann es umdefinieren.
Egal wie klein ein Marktsegment ist, Microsoft wird es für sich beanspruchen.
Ansonsten gibt es das Programm im Internet kostenlos.
Doppelregel für Hobbyprogrammierer:
Führst du ein selbstprogrammiertes Programm vor, dann stösst du beim ersten Mal auf einen offensichtlichen Fehler.
Gravierende Fehler sind von dir nicht reproduzierbar. Sie werden allerdings von jedem bemerkt, der ausser dir dein Programm startet.
Axels Erkenntnis vom Debugging:
Nichts verbessert ein Programm so sehr wie das Fehlen von Kontrollroutinen.

Axels erweiterte Erkenntnis:
Wenn Debugging der Vorgang ist, Fehler aus einem Programm auszubauen, dann ist Programmieren der Vorgang Fehler einzubauen.

Axels Folgerung:
Wenn du nicht weisst, was du tust - mach es elegant.

Erster Grundsatz der EDV-Spezialisierung:
Jeder Entwickler, der von ausserhalb der Stadt kommt, ist ein Fachmann.

Zweiter Grundsatz der EDV-Spezialisierung:
Ein Spezialist ist jemand, der immer mehr über immer weniger weiss, bis er zum Schluss absolut alles über gar nichts weiss. Dann nennt man ihn Berater.

Clarkes Reihenfolge der Softwareentwicklung:
Es ist unmöglich - ich verschwende doch nicht meine Zeit.
Es ist möglich, aber nichts wert.
Ich sage ja, dass diese Idee von mir grossartig ist.
Kann mir mal jemand sagen, warum die Konkurrenz schon wieder schneller war?
Mexners Speicheraxiom:
Programmcode neigt dazu, den kompletten zur Verfügung stehenden Speicher auszufüllen und zu überschreiten.

Die Zerberus-Erweiterung:
Wenn du sämtliche Kommentarzellen löschst und umständliche Programmroutinen neu und kürzer programmierst, wird das Programm hinterher länger sein, mehr Speicherplatz benötigen, zu gross für den Compiler sein und darüber hinaus nicht mehr funktionieren.

Gesetze vom Arbeitszimmer:
Alle horizontalen Flächen werden in kurzer Zeit von Gerümpel bedeckt sein.
Die CDs liegen darunter.
Das dringend benötigte Pflichtenheft ist nirgends.
Zigarettenasche und Kaffee befinden sich irgendwo dazwischen.
Der Katastrophenschutz:
Wer lächelt, wenn etwas schief geht, weiss einen, den er dafür verantwortlich machen kann.

Die acht ehernen Kundengesetze:
Es kommt einem Kunden nie darauf an, was ein Projekt kostet, sondern wie viel er dabei einspart.
Wenn du ein Programm erfolgreich ergänzt hast, wird es der Kunde nicht mehr haben wollen.
Kein Kunde weiss, was er eigentlich will.
Jeder Kunde weiss, was er nicht will.
Kein Kunde will das, was du bereits fertiggestellt hast.
Er weiss auch nicht, was er stattdessen möchte.
Der Kunde, der am wenigsten zahlt, meckert am meisten.
Grössere Änderungen wird der Kunde immer dann verlangen, wenn ein Produkt eben ausgeliefert wurde.
Merksatz vom zeitverzögerte Bug:
Du wirst den entscheidenden Fehler erst dann bemerken, wenn das Programm sechs Monate lang fehlerfrei lief.
Dieser Fehler wird die Daten verfälscht oder vernichtet haben, die nicht wiederherstellbar sind und auf die es bei dem Programm in erster Linie ankam.
Der Quellcode ist inzwischen unauffindbar.
Peters Gesetz vom Spaghetticode:
Die Programmverwicklung wächst so lange, bis sie die Fähigkeiten des Programmierers übertrifft, der es weiterentwickeln muss.

Die Erweiterung von Peters Gesetz:
Die Vorarbeit wurde immer von Leuten ausgeführt, die im Begriff waren, die höchste Stufe ihrer Unfähigkeit zu erreichen.

Das Analyse-Axiom:
Nach sorgfältiger Analyse der Programmstruktur und grossem Aufwand wird festgestellt werden, dass es das falsche Programm ist und bei der zu lösenden Aufgabe nicht verwendet werden kann.

Prämisse von unveränderlichen Daten:
Anstrengung x Zeit = konstant.

Erste Ableitung der Stressprämisse:
Wenn du noch viel Zeit hast, wirst du wenig Anstrengung investieren.

Zweite Ableitung der Stressprämisse:
Nähert sich die zur Verfügung stehende Zeit dem Wert Null, wächst die Anstrengung ins Unendliche.

Dritte Ableitung der Stressprämisse:
Ohne die "letzte Minute" würdest du nie irgend etwas erledigen.

Allgemeine Konzeptionsgesetze:
Du hast niemals Zeit, es richtig zu machen, aber beliebig viel Zeit, es nochmals zu machen.
Alles, was an dem Pflichtenheft eines Programms änderbar ist, wird so lange geändert, bis es zu spät ist, noch irgend etwas am Programm selbst zu ändern.
Rüdigers Gesetze vom Debugging:
In jedem Programm neigen Fehler dazu, am entgegengesetzten Ende deiner Fehlersuche aufzutreten.
Wenn ein Listing Fehler aufweist, sieht es fehlerfrei aus.
Wenn ein Fehler entdeckt und korrigiert wurde, stellt sich heraus, dass es schon zu spät ist.
War es nicht zu spät, war die Korrektur falsch und der ursprüngliche Text richtig.
Folgerung 1:
Nachdem die Korrektur falsch war, wird es unmöglich sein, den Anfangszustand wieder herzustellen.

Folgerung 2:
Von zwei möglichen schlechten Ergebnissen wird nur das tatsächlich eintreten, bei dem der Fehler auf dich zurückzuführen ist.

Das Qualitätssyndrom:
Jedes Programm, das gut beginnt, endet schlecht. Ein Projekt, dessen Programmierung schlecht beginnt, endet furchtbar.

Folgerung 1:
Was einfach aussieht, ist schwierig. Was schwierig aussieht, ist unmöglich. Was unmöglich aussieht, kann sogar die Putzfrau ohne Computer lösen.

Folgerung 2:
Eine Grenze dafür, wie schlimm es noch werden kann, gibt es nicht.

Folgerung 3:
Die Putzfrau hat längst bei der Konkurrenz als Systemprogrammiererin angefangen.

Wulfs Prinzip der geringsten Verwunderung:
Wenn etwas einmal auf eine bestimmte Art realisiert wurde, dann muss es immer und überall so realisiert werden.

Die Softwareteam-Ableitung:
Zur Lösung von Programmierproblemen hat jeder im Softwareteam mindestens einen Plan, der nicht funktioniert.

Erste Folgerung:
Jeder Fehler wird dort sitzen, wo er am spätesten entdeckt wird und den grösstmöglichen Schaden anrichtet.

Zweite Folgerung:
Jeder Fehler tritt erst dann auf, wenn das Gesamtprogramm die letzte Kontrolle durchlaufen hat.

Dritte Folgerung:
Wird der Fehler früher bemerkt, ist die Ursache nicht zu finden.

Gesetz vom Schluss:
Die Fertigstellung eines Programms braucht immer doppelt so lang wie geplant. Wird dieses Gesetz beim Zeitplan berücksichtigt, so gilt der Satz der Rekursion.

Der Adaptionslehrsatz:
Die Anpassung eines Programms auf ein anderes Computersystem bewirkt, dass es auf dem Rechner, für den es ursprünglich geschrieben wurde, nicht mehr lauffähig ist. Der Versuch der Anpassung an den ersten Rechner bewirkt, dass das Programm auf keinem der beiden Rechner läuft.

Die Multiplikationstheorie:
Die Zahl der Personen in einem Programmierteam neigt zur Zunahme ohne Rücksicht auf die Menge der anfallenden Arbeit.

Ergänzung:
Tust du jemandem einen Gefallen, dann bist du ab sofort und auf Dauer verantwortlich.

Robbins Grenzwertbestimmung:
Die Minimalanforderung im Pflichtenheft sind zugleich das Maximum an Leistung, das auf dem geforderten Computertyp realisierbar ist.

Hertz Unsicherheitsfaktor:
Unklarheit ist eine unveränderlicher Grösse.

Gesetz über die Programmänderung:
Je einfach einer Änderung zu sein scheint, umso grössere Kreise zieht sie und umso mehr Routinen müssen neu geschrieben werden.

Vereinfachende Ableitungen:
Wo ein Wille ist, ist auch ein "geht nicht".
Nichts ist so einfach, dass man es nicht falsch machen kann.
Die Abfangregel:
Wenn du eine Routine entwickelst, die offensichtlich Fehler vor der Ausgabe abfängt, wird es Anwender geben, die sich diese fehlerhaften Daten schon zuvor, unter Umgehung dieser Abfangroutine, besorgen können.

Axiom von der Recherche:
Die Information, die am dringendsten benötigt wird, ist am wenigsten erreichbar.

Gesetz von der Findigkeit des Anwenders
("4+1=5-Gesetz"):
Wenn man feststellt, dass es vier verschiedene Möglichkeiten gibt, ein Programm zum Absturz zu bringen, und man schaltet diese vier aus, findet der erste Anwender eine fünfte.

Verallgemeinerung:
Du kannst jedes Programm narrensicher machen, aber keines verdammt narrensicher.

Das Dokumentationsgesetz:
Ein Handbuch wird nicht gelesen. Die FAQ auf der Webseite ist nutzlos.

Beweis des Dokumentationsgesetzes:
Wenn du jemandem erzählst, dass es 3*1011 Sterne im Universum gibt, wird er dir glauben - wenn du ihm sagst, dass die Bank, vor der er steht, frisch gestrichen ist, wird er sie anfassen.

Ausnahmen:
Schlechte Handbücher werden von Testredakteuren gelesen.
Es werden nur die Abschnitte im Handbuch gelesen, die einen Anwender dazu veranlassen, das Falsche zu tun.
Jedes Handbuch ist bei Drucklegung veraltet, die Online-Version ist ausschliesslich in der vorletzten Version verfügbar.
Axiom von der Relation Handbuch/Programm:
Wenn du etwas so genau erklärst, dass es nicht missverstanden werden kann, wird es irgendwer doch tun.

Gesetz vom Zusammenhang zwischen Testbericht und Handbuch
("CT-Gesetz"):
Machst du ein gutes Handbuch, ist es dem Testredakteur nicht ausführlich genug.
Machst du ein gutes und ausführliches Handbuch, werden Handbücher beim Test nicht bewertet.
Machst du ein schlechtes Handbuch, ist es das ausschlaggebende Kriterium für die Testberichte in allen Fachzeitschriften.
Daniels Gesetze über Testberichte:
Dein Programm wird von Computerzeitschriften so lange nicht getestet, bis Konkurrenzprodukte auf den Markt gebracht werden, die besser sind.
Trifft Satz 1 nicht zu, wird der Testredakteur behaupten, dass die herausragenden Features deines Programms keiner braucht.
Treffen Satz 1 und Satz 2 nicht zu, hat der Testredakteur die herausragenden Features deines Programms nicht bemerkt.
Daniels Ableitungen:
Dein Programm schneidet immer am schlechtesten ab.
Das beste Testergebnis bekommt immer dein härtester Konkurrent.
Die Wertung ist um so katastrophaler, je wichtiger die testende Zeitschrift für die anvisierte Zielgruppe ist.
Dogma vom hinterlistigen Algorithmus:
Wenn ein Programm funktioniert, ist vorher etwas schief gegangen.

Folgerungen aus dem Dogma vom hinterlistigen Algorithmus:
Egal was schief geht, es wird richtig aussehen.
Derjenige, den du um Hilfe bittest, wird den Fehler nicht bemerken.
Derjenige, der mit unerbetenen Ratschlägen dazukommt, wird ihn sofort entdecken.
Egal was schief geht, immer ist jemand da, der es schon vorher wusste.
Glaube nicht an Wunder - verlass dich auf sie.
Die Tempelmann-Erkenntnis vom eleganten programmieren:
Komplexe Probleme haben einfache, leicht umzusetzende, aber falsche Lösungen.

Verallgemeinerung:
Die Abkürzung ist die weiteste Entfernung zwischen zwei Punkten.

Positive Ausnahme:
Eine gute Lösung kann praktisch auf jedes Problem angewendet werden. Dabei werden sich jedoch sowohl Problem als auch Lösung zu ihrem Nachteil verändern.

Allgemeine Algorithmentheorie:
Jede Formel und jede Konstante muss als Variable betrachtet werden.
Die wesentliche Dimension eines Algorithmus hat die grösste Chance, weggelassen und/oder vergessen zu werden.
Sobald ein Programmmodul perfekt funktioniert, wird es mit den anderen Modulen nicht zusammenarbeiten.
Nichts endet jemals so wie geplant.
In einer gegebenen Aufgabe, die n Gleichungen enthält,, werden sich mit Sicherheit n+1 Unbekannte verstecken.
Theoretisches Gesetz der Programmiersprachen-Kompatibilität
(Java-Axiom):
Prämisse: Selbst wenn es gelänge, alle Programmiersprachen der Welt durch eine einzige einheitliche Programmiersprache zu ersetzen - es wird auch dann immer genug Hersteller geben, die diese einzige einheitliche Programmmiersprache in einer eigenen Spezialentwicklung auf den Markt zu bringen.
Folgerung: Diese Spezialentwicklungen werden zu nichts kompatibel sein ausser zu sich selbst.
Einschränkung: Die Inkompatibilität erstreckt sich selbstverständlich auch auf verschiedene Versionsnummern derselben Spezialentwicklung.
Praktische Anwendung der Programmiersprachen-Kompatibilität:
Da es keine einzige einheitliche Programmiersprache gibt, ist das Wirrwarr total.
Du darfst es ausbaden.
Die 90-90-10-Regelung des Programmierprojekts:
Die ersten 90 Prozent des Programms brauchen 10 Prozent der verfügbaren Zeit.
Die restlichen 10 Prozent des Programms brauchen 90 Prozent der verfügbaren Zeit.
Du fängst immer mit diesen restlichen 10 Prozent an.
Konsequente Kundenableitung aus der 90-90-10-Regelung:
Die 10 Prozent, mit denen du angefangen hast, gehören zu der Programmroutine, die der Kunde zu guter Letzt wieder entfernt haben will.

Grays Programmiergesetz:
Für n+1 unwichtige Aufgaben wird die gleiche Zeit zur Durchführung erwarte wie für n Aufgaben.

Die erweiterte Epstein-Heisenberg-Unschärferelation:
Von den Parametern Zeit, Geld und Aufgabe lassen sich immer nur zwei zur gleichen Zeit exakt berechnen:

Wenn die Aufgabe und die zur Verfügung stehende Zeit bekannt sind, ist es unmöglich zu berechnen, wie teuer das Ganze wird.
Wenn die zur Verfügung stehende Zeit und der Etat bekannt sind, wird niemand wissen, welcher Teil der Aufgabe zu lösen ist.
Wenn die Aufgabe und auch der zur Verfügung stehende Etat bekannt sind, dann wird keiner wissen, ob und wann das Ziel erreicht wird.
Wer alle drei Parameter bestimmen kann, befasst sich nicht mit dem Bereich der Aufgabenstellung.
Anabells Projektkontrollen-Konkretisierungen:
Ein schlecht geplantes Programmierprojekt wird dreimal länger dauern als ein gut geplantes. Ein gut geplantes auch.
Projektteams wehren sich gegen regelmässiges Reporting, weil dieses zeigt, wie langsam sie vorankommen.
Ungenaue Projektdefinitionen dienen dazu, die Kostenüberschreitung zu legitimieren.
Genaue Projektdefinitionen dienen dazu, die Zeitüberschreitung zu legitimieren.
Postulat vom Pflichtenheft:
Ausnahmen sind grundsätzlich zahlreicher als Regeln.
Von allen anerkannten Ausnahmen gibt es Ausnahmen.
Wenn man die Ausnahmen endlich im Griff hat, erinnert sich keiner mehr an die Regeln, für die sie gelten sollen.
Gesetz des Ärgers:
Sobald du eine Datei löschst, weil du sicher bist, dass du sie nie wieder benötigst, wirst du sie sofort benötigen.

Das Compiler-Strukturgesetz:
Je mehr Strukturbefehle du in deinem Programm verwendest, umso weniger wird dein Compiler übersetzen.

Ergänzung zum Compiler-Strukturgesetz:
Übersetzt werden nur die fehlerhaften Strukturen.

Erste Erweiterung des Compiler-Strukturgesetzes:
Wenn der Compiler ein Programm beim ersten Durchlauf ohne Fehler akzeptiert, wird das fertige Programm nicht den gewünschten Output liefern.

Zweite Erweiterung des Compiler-Strukturgesetzes:
Verzichtest du auf strukturierte Programmierung, wird der Compiler unverständliche Fehlermeldungen produzieren. Die dazugehörigen Fehler wirst du in deinem Spaghetticode nicht finden.

Das Zeichenkonvertierungsgesetz:
Du kannst Gross- in Kleinbuchstaben und Klein- in Grossbuchstaben umwandeln. Als Ergebnis wirst du aber stets einen Text erhalten, bei dem die Hälfe aller Kleinbuchstaben gross und die Hälfte Grossbuchstaben klein geschrieben sind.
Du kannst den Anfangszustand nicht wiederherstellen.
Richtig geschrieben bekommst du den Text nur per Hand.
Am Ende ist weniger Arbeit, den ganzen Text neu einzutippen.
Frankes Blumenerkenntnis:
Egal womit man die Blumen giesst: Die Hälfte dessen läuft immer über die Listings.

Helmuts Befehlsaxiom:
Ein Befehl kann gar nicht so kurz sein, als dass man nicht mindestens dreimal einen Tippfehler einbauen kann.

Ergänzung zu Helmuts Befehlsaxiom:
Tippst du den Befehl fehlerfrei ein, wirst du zwischen Befehl und abschliessendem Return wahlweise ein "<" ein "#" oder ein "+" schieben.
Du wirst nie <RETURN> allein drücken können.
Wenn du das "#" einmal brauchst, findest du es auf deiner Tastatur nicht.
Erkenntnis des Anwendungsprogrammierers:
Grundsatz: Ein Anwender macht immer das Falsche.

Schreibst du "Tippe (J) oder (N), tippt er "(J) oder (N)"
Schreibst du "Drücke (RETURN)", tippt er "(RETURN)"
Schreibst du "Drücke irgendeine Taste", drückt er auf SHIFT oder betätigt die NUMLOCK-Taste.
Schreibst du "Klicken Sie OK", wer den OK-Button im anderen Fenster nehmen.
In keinem Fall wird er einen Systemhinweis zur Kenntnis nehmen.
Mulis Registererkenntnis:
Speicherst du etwas in einem Register, und merkst dir genau, was du dort gespeichert hast, vergisst du das Register.
Merkst du dir das Register, dann wirst du den Inhalt nicht mehr benötigen.
Die drei grundlegenden Softwarehaus-Irrtümer:
Je grösser das Programmiervorhaben, umso später werden grundlegende Ablauffehler entdeckt.
Wenn ein Problem verschwunden ist, gibt es immer noch Leute, die an der Lösung arbeiten.
Mehr Leute für ein überfälliges Programmierprojekt abzustellen, verzögert die Fertigstellung.
Grundsatz des Software-Engineering:
Zeit isst Geld.

Treplins Stossseufzer:
Es gibt zwei Methoden, fehlerfreie Programme zu schreiben, aber nur die dritte funktioniert.

Ohlmeiers Grundregeln von der Programmierung:
Den Befehl, den du brauchst, hast du vergessen.

Wenn du den Befehl noch kennst, weisst du die Parameter nicht mehr.

Kennst du beides, verwechselst du die Reihenfolge der Parameter.

Schlussfolgerung aus Ohlmeiers Grundregeln:
Du musst am Schluss sowieso im Handbuch nachschauen.

Verschärfung:
Erst dann wirst du feststellen, dass dein Problem mit einem anderen Befehl einfacher zu lösen gewesen wäre.

Helmuts Befehlsaxiom:
Ein Befehl kann gar nicht so kurz sein, als dass man nicht mindestens dreimal einen Tippfehler einbauen kann.