1. Programmierer

 

Programmierer sind (trotz anderslautender 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 Bedienern deren einander widersprechende Anforderungen in Programme umzusetzen, die am Schluss niemand verwendet.

Programmierer zerfallen in zwei Kategorien. Die eine Sorte versagt bei dem Versuch, für viel zuwenig Geld mit viel zuviel Aufwand die logischen Irrtümer von Programmiersprachen, die Fehler von Compilern und die in Silizium gegossenen Ungereimtheiten der Hardwareentwickler so gegebeinander auszuspielen, daß das Computersystem am Schluß wenigstens hin und wieder das tut, was man von ihm erwartet. Die andere Sorte tut dieses ganz umsonst.

Generell ist das Denken eines Programmierers logisch (»IF 1=2 CALL Mainprogram«), stets strukturiert (»ON Hunger GOSUB Aldi ELSE RETURN«) und von keinerlei Vorurteilen beeinträchtigt. Obwohl es einzelne Vertreter dieses Berufszweigs geben soll, die dem Vorurteil nachhängen, daß 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.

Obwohl es schwierig ist, Murphys Computergesetz aus der Sicht des Programmierers zu schildern (schließlich ist ein Programmierer das im Grunde völlig überflüssige Glied der Kette Marketingabteilung – Werbeabteilung – Programmierer – Vertriebsabteilung – Anwender – Supportabteilung – Updateabteilung), soll auf den folgenden Seiten der Versuch dazu unternommen werden. Auch wenn sich Softwarehäuser und Anwender seit Jahren darüber einig sind, daß 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, daß andere Computer sie auch in der richtigen Art mißverstehen 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 perfekt beherrschen.

Schlußfolgerung:

Ein Computer wird das tun, was Du programmierst – nicht das, was Du willst.

Doppelregel für Hobbyprogrammierer:

1. Führst Du ein selbstprogrammiertes Programm vor, dann stößt Du beim ersten Mal auf einen offensichtlichen Fehler.

2. Gravierende Fehler sind von Dir nicht reproduzierbar. Sie werden allerdings von jedem bemerkt, der außer 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 weißt, was Du tust – mach es ele-gant.

Erster Grundsatz der EDV-Spezialisierung:

Jeder Entwickler, der von außerhalb der Stadt kommt, ist ein Fachmann.

Zweiter Grundsatz der EDV-Spezialisierung:

Ein Fachmann ist jemand, der immer mehr über immer weniger weiß, bis er zum Schluß absolut alles über gar nichts weiß.

Clarkes Reihenfolge der Softwareentwicklung:

1. Es ist unmöglich – ich verschwende doch nicht meine Zeit.

2. Es ist möglich, aber nichts wert.

3. Ich sage ja, daß diese Idee von mir großartig ist.

4. Kann mir mal jemand sagen, warum die Konkurrenz schon wieder schneller war?

Maxners Speicheraxiom:

Programmcode neigt dazu, den kompletten, zur Verfügung stehenden Speicher auszufüllen und zu überschreiben.

Die Zerberus-Erweiterung:

Wenn Du sämtliche Kommentarzeilen löscht und umständliche Programmroutinen neu und kürzer programmierst, wird das Programm hinterher länger sein, mehr Speicherplatz benötigen, zu groß für den Compiler sein und darüber hinaus nicht mehr funktionieren.

Gesetze vom Arbeitszimmer:

1. Alle horizontalen Flächen werden in kurzer Zeit von Gerümpel bedeckt.

2. Die Disketten liegen darunter.

3. Das dringend benötigte Pflichtenheft ist nirgends.

4. Zigarettenasche und Kaffee befinden sich irgendwo dazwischen.

Der Katastrophenschutz:

Wer lächelt, wenn etwas schiefgeht, weiß einen, den er dafür verantwortlich machen kann.

Die acht ehernen Kundengesetze:

1. Es kommt einem Kunden nie darauf an, was ein Projekt kostet, sondern wieviel er dabei einspart.

2. Wenn Du ein Programm erfolgreich ergänzt hast, wird es der Kunde nicht mehr haben wollen.

3. Kein Kunde weiß, was er eigentlich will.

4. Jeder Kunde weiß, was er nicht will.

5. Kein Kunde will das, was Du bereits fertiggestellt hast.

6. Er weiß auch nicht, was er statt dessen möchte.

7. Der Kunde, der am wenigsten zahlt, meckert am meisten.

8. Größere Änderungen wird der Kunde immer dann verlangen, wenn ein Produkt eben ausgeliefert wurde.

Merksatz vom zeitverzögerten Bug:

1. Du wirst den entscheidenden Fehler erst dann entdecken, wenn das Programm sechs Monate lang fehlerfrei lief.

2. 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.

3. 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 muß.

Die Erweiterung von Peters Gesetz:

Die Vorarbeit wurde immer von Personen ausgeführt, die dabei sind, die höchste Stufe ihrer Unfähigkeit zu erreichen.

Das Analyse-Axiom:

Nach sorgfältiger Analyse der Programmstruktur und mühevollem Aufwand wird festgestellt werden, daß es das falsche Programm ist und bei der zu lösenden Aufgabe nicht verwendet werden kann.

Prämisse vom unveränderlichen Streß:

Anstrengung mal Zeit = konstant.

Erste Ableitung der Streßprämisse:

Wenn Du noch viel Zeit hast, wirst Du wenig Anstrengung investieren.

Zweite Ableitung der Streßprämisse:

Nähert sich die zur Verfügung stehende Zeit dem Wert Null, wächst die Anstrengung ins Unendliche.

Dritte Ableitung der Streßprämisse:

Ohne die »letzte Minute« würdest Du nie irgendetwas erledigen.

Allgemeine Konzeptionsgesetze:

1. Du hast niemals Zeit, es richtig zu machen, aber beliebig viel Zeit, es nochmals zu machen.

2. 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:

1. In jedem Programm neigen Fehler dazu, am entgegengesetzten Ende Deiner Fehlersuche aufzutreten.

2. Wenn ein Listing Fehler aufweist, sieht es fehlerfrei aus.

3. Wenn ein Fehler entdeckt und korrigiert wurde, stellt sich heraus, daß es schon zu spät ist.

4. 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 wiederherzustellen.

Folgerung 2:

Von zwei möglichen schlechten Ereignissen 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 an einer Stelle auf eine Art realisiert wurde, dann muß 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.

Das Routinengesetz:

1. Jede Programmroutine, in die sich ein Fehler einschleichen kann, wird auch einen enthalten.

2. Auch in Routinen, die fehlerlos sein müssen, sind Fehler.

Erste Folgerung:

Jeder Fehler wird dort sitzen, wo er am spätesten entdeckt wird und den größtmö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 Schluß:

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, daß es auf dem Rechner, für das es ursprünglich geschrieben wurde, nicht mehr lauffähig ist. Der Versuch der anpassung an den ersten Rechner bewirkt, daß 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 auf die Dauer dafür verantwortlich.

Robbins Grenzwertbestimmung:

Die Minimalanforderungen im Programmpflichtenheft sind zugleich das Maximum an Leistung, das auf dem geforderten Computertyp realisierbar ist.

Hartz' Unsicherheitsfaktor:

Unklarheit ist eine unveränderliche Größe,

Gesetz über die Programmänderung:

Je einfacher eine Änderung zu sein scheint, um so größere Kreise zieht sie und um so mehr Routinen müssen neu geschrieben werden.

Vereinfachende Ableitungen:

1. Wo ein Wille ist, ist auch ein »geht nicht«.

2. Nichts ist so einfach, daß man es nicht falsch machen kann.

Die Abfangregel:

Wenn Du eine Routine entwickelst, die offensichtliche 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:

Wenn man feststellt, daß 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.

Ausnahmen:

1. Schlechte Handbücher werden von Testredakteuren gelesen.

2. Es werden nur die Abschnitte im Handbuch gelesen, die einen Anwender dazu veranlassen, das falsche zu tun.

3. Jedes Handbuch ist bei Drucklegung veraltet.

Axiom von der Relation Handbuch/Programm:

Wenn Du etwas so genau erklärst, daß es nicht mißverstanden werden kann, wird es irgendwer doch tun.

Vogels Zusammenhang zwischen Testbericht und Handbuch:

1. Machst Du ein gutes Handbuch, ist es dem Testredakteur nicht ausführlich genug.

2. Machst Du ein gutes und ausführliches Handbuch, werden Handbücher beim Test nicht bewertet.

3. Machst Du ein schlechtes Handbuch, ist es das ausschlaggebende Kriterium für die Testberichte in allen Computerzeitschriften.

Daniels Gesetze über Testberichte:

1. Dein Programm wird von Computerzeitschriften so lange nicht getestet, bis Konkurrenzprodukte auf den Markt gebracht werden, die besser sind.

2. Trifft Satz 1 nicht zu, wird der Testredakteur behaupten, daß die herausragenden Features Deines Programms keiner braucht.

3. Treffen Satz 1 und Satz 2 nicht zu, hat der Testredakteur die herausragenden Features Deines Programms nicht bemerkt.

Daniels Ableitungen:

1. Dein Programm schneidet immer am schlechtesten ab.

2. Das beste Testergebnis bekommt immer Dein härtester Konkurrent.

3. Die Wertung ist um so katastophaler, je wichtiger die testende Zeitschrift für die anvisierte Zielgruppe ist.

Dogma vom hinterlistigen Algorithmus:

Wenn ein Programm funktoniert, ist vorher etwas schiefgegangen.

Folgerungen aus dem Dogma vom hinterlistigen Algorithmus:

1. Ganz egal, was schiefgeht, es wird richtig aussehen.

2. Derjenige, den Du um Hilfe bittest, wird den Fehler nicht bemerken.

3. Derjenige, der mit unerbetenen Ratschlägen dazukommt, wird ihn sofort entdecken.

4. Egal, was schiefgeht, immer ist jemand da, der es schon vorher wußte.

5. Glaube nicht an Wunder – verlaß 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 längste 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:

1. Jede Formel und jede Konstante muß als Variable betrachtet werden.

2. Die wesentliche Dimension eines Algorithmus hat die größte Chance, weggelassen und/oder vergessenen zu werden.

3. Sobald ein Programm-Modul perfekt funktioniert, wird es mit den anderen Modulen nicht zusammenarbeiten.

4. Nichts endet jemals so wie geplant.

5. In einer gegebenen Aufgabe, die n Gleichungen enthält, werden sich mit Sicherheit n+1 Unbekannte verstecken.

Theoretisches Gesetz der Programmiersprachen-Kompatibilität (unter dem Namen »Turbo-... / Quick-... Axiom« weltberühmt geworden):

1. Prämise: Selbst wenn es gelänge, alle Programmiersprachen der Welt durch eine einzige einheitliche Programmiersprache zu ersetzen – es wird auch dann noch genug Hersteller geben, die diese einzige, einheitliche Programmiersprache in einer eigenen Spezialentwicklung auf den Markt bringen.

2. Folgerung: Diese Spezialentwicklung wird zu nichts kompatibel sein außer zu sich selbst.

3. Einschränkung: Die Inkompatibilität erstreckt sich aber selbstverständlich auch auf verschiedene Versionsnummern derselben Spezialentwicklung.

Praktische Anwendung Programmiersprachen-Kompatibilität:

1. Da es keine einzige, einheitliche Programmiersprache gibt, ist das Wirrwarr total.

2. Du darfst es ausbaden.

Die 90-90-10-Regelung des Programmierprojekts:

1. Die ersten 90 Prozent des Programms brauchen 10 Prozent der verfügbaren Zeit.

2. Die restlichen 10 Prozent des Programms brauchen 90 Prozent der verfügbaren Zeit.

3. Du fängst immer mit diesen restlichen 10 Prozent an.

Konsequente Kunden-Ableitung 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 erwartet 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:

1. Wenn die Aufgabe bekannt ist und die zur Verfügung stehende Zeit, ist es unmöglich zu berechnen, wie teuer das Ganze wird.

2. Wenn die zur Verfügung stehende Zeit und der Etat bekannt sind, wird niemand wissen, welcher Teil der Aufgabe zu lösen ist.

3. Wenn die Aufgabe bekannt ist und auch der zur Verfügung stehende Etat, dann wird keiner wissen, ob und wann das Ziel erreicht wird.

4. Wer alle drei Parameter bestimmen kann, befaßt sich nicht mit dem Bereich der Aufgabenstellung.

Postulat vom Pflichtenheft:

1. Ausnahmen sind grundsätzlich zahlreicher als Regeln.

2. Von allen anerkannten Ausnahmen gibt es Ausnahmen.

3. 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, daß Du sie nie wieder brauchst, wirst Du sie sofort benötigen.

Das Compiler-Strukturgesetz:

Je mehr Strukturbefehle Du in Deinem Programm verwendest, um so 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 erwünschten Output liefern.

Zweite Erweiterung des Compiler-Strukturgesetzes:

Verzichtest Du auf strukturierte Programmierung, wird der Computer unverständliche Fehlermeldungen produzieren. Die dazugehörigen Fehler wirst Du in Deinem Spaghetticode nicht finden.

Das Zeichenkonvertierungsgesetz:

1. Du kannst Groß- nach Kleinbuchstaben und Klein- nach Großbuchstaben wandeln. Als Ergebnis wirst Du aber stets einen Text erhalten, bei dem die Hälfte aller Kleinbuchstaben groß und Großbuchstaben klein geschrieben sind.
2. Du kannst den Anfangszustand nicht wieder herstellen.
3. Richtig geschrieben bekommst Du den Text nur per Hand.
4. Am Ende ist es weniger Arbeit, den ganzen Text neu einzutippen.

Frankes Blumenerkenntnis:

Egal, womit man die Blumen gießt: die Hälfte davon läuft immer über die Listings.

Helmuts Befehlsaxiom:

Ein Kommando kann gar nicht so kurz sein, als daß man nicht mindestens dreimal einen Tippfehler einbauen kann.

Ergänzung zu Helmuts Befehlsaxiom (auch das Entweder »<« oder »#« Gesetz genannt):

Tippst Du den Befehl fehlerfrei, wirst Du zwischen Befehl und abschließendem Return wahlweise ein »<«, ein »#« oder ein »+« schieben.

Erkenntnis des Anwendungsprogrammierers:

Grundsatz: Ein Anwender macht immer das Falsche:

1. Schreibst Du »Tippe (J) oder (N)«, tippt er »(J) oder (N)«.

2. Schreibst Du »Drücke [RETURN]« tippt er »[RETURN]«.

3. Schreibst Du »Drücke irgendeine Taste«, drückt er auf SHIFT oder betätigt die NUMLOCK-Taste.

Mulls Registererkenntnis:

1. Speicherst Du etwas in einem Register und merkst Dir genau, was Du dort gespeichert hast, vergißt Du das Register.

2. Merkst Du Dir das Register, dann wirst Du den Inhalt nicht mehr benötigen.

Die Freitag-Montag-Regel:

Ein Programm, das Du freitags ablieferst, siehst Du montags wieder.

Die drei grundlegenden Softwarehaus-Irrtümer:

1. Je größer das Programmiervorhaben, um so später werden grundlegende Ablauffehler entdeckt.

2. Wenn ein Problem verschwunden ist, gibt es immer noch Leute, die an einer Lösung arbeiten.

3. Mehr Leute für ein überfälliges Programmierprojekt abzustellen, verzögert die Fertigstellung.

Die Softwarehaus-Erkenntnis:

Dringlichkeit ist der Wichtigkeit umgekehrt proportional.

Grundsatz des Software-Engineerings:

Zeit ißt Geld.

Trepplins Stoßseufzer:

Es gibt zwei Methoden, fehlerfreie Programme zu schreiben. Aber nur die dritte funktioniert.