German translation of Neil W. Rickert's "The Parable of the Two Programmers" from 1985
The Parable of the Two Programmers by Neil W. Rickert
Es waren einmal, einander unbekannt, die "Automated Accounting Applications Association" und die "Consolidated Computerized Capital Corporation". Beide hatten genau das gleiche Problem, für das sie genau das gleiche Programm benötigten.
Automated heuerte den Analytiker Alan an, auf dass er ihr Problem lösen möge.
Zur gleichen Zeit entschied sich Consolidated für Charles, ihrem frisch eingestellten Einstiegsprogrammierer, auf dass er sich beweisen solle.
Alan hatte bereits Erfahrung mit schwierigen Softwareprojekten und entschied sich, die PQR-Methode für strukturiertes Design anzuwenden. Hierzu bat er seinen Abteilungsleiter um drei weitere Programmierer. Das Team machte sich an die Arbeit und produzierte am laufenden Band vorläufige Berichte und Problemanalysen.
Drüben bei Consolidated verbrachte Charles einige Zeit damit, über das Problem nachzudenken. Seinen Arbeitskollegen fiel auf, dass er oft seine Füße auf den Tisch legte und dabei Kaffee trank. Gelegentlich wurde er an seinem Computerterminal gesehen, doch sein Bürokamerad konnte an den rhythmischen Tastaturanschlägen erkennen, dass er eigentlich Space Invaders spielte.
Inzwischen begann das Team bei Automated damit, Programmcode zu schreiben. Die Programmierer verbrachten die Hälfte ihrer Zeit mit dem Schreiben und Compilieren von Code, und die übrige Zeit in Besprechungen, in denen sie die Schnittstellen zwischen den verschiedenen Modulen diskutierten.
Sein Bürokamerad bemerkte, dass Charles endlich Abstand von Space Invaders nahm. Stattdessen teilte er seine Zeit nun in "Kaffeetrinken mit hochgelegten Füßen" und "Bekritzeln kleiner Papierfetzen" auf. Seine Kritzeleien sahen nicht nach Tic-Tac-Toe aus, aber sie ergaben auch nicht wirklich Sinn.
Zwei Monate sind vergangen. Das Team bei Automated gibt einen Zeitplan für die Implementierung heraus. In weiteren zwei Monaten würden sie eine Testversion des Programmes haben, gefolgt von einer zweimonatigen Test- und Verbesserungs-Phase, die schließlich die fertige Version liefern sollte.
Inzwischen hat Charles' Manager die Faulenzerei endgültig satt und entschließt sich zur Konfrontation. Doch als er Charles' Büro betritt, überrascht es ihn zu sehen, dass Charles fleißig Code in sein Terminal eintippt. Er entschließt sich, die Konfrontation zu verschieben, und verlässt das Büro nach einem kurzen Plausch gleich wieder. Jedoch behält er Charles im Auge, um die Konfrontation bei passender Gelegenheit nachzuholen. Doch er ist nicht wild auf das unangenehme Gespräch, und so freut es ihn zu sehen, dass Charles nun die meiste Zeit über beschäftigt ist. Man sieht ihn sogar sein Mittagessen aufschieben und an zwei bis drei Tagen in der Woche Überstunden machen.
Am Ende der drei Monate verkündet Charles die Fertigstellung des Projekts. Er legt ein 500-zeiliges Programm vor. Das Programm ist gut verständlich geschrieben und erfüllt offenbar alles, was die Spezifikation verlangt. Es hat sogar ein paar zusätzliche Komfort-Features, welche die Benutzerfreundlichkeit des Programmes deutlich erhöhen dürften. Das Programm wird der Prüfung unterzogen und schneidet dort, bis auf einen schnell behobenen Flüchtigkeitsfehler, sehr gut ab.
Das Team bei Automated hat nun zwei der vier Hauptmodule ihres Programms fertiggestellt. Diese Module werden nun durchgeprüft, während die übrigen Module fertiggestellt werden.
Nach weiteren drei Wochen verkündet Alan, dass die Vorab-Version eine Woche vor dem Zeitplan einsatzbereit ist. Er stellt eine Liste von Mängeln bereit, die er demnächst beheben werde. Das Programm wird der Prüfung unterzogen. Die Benutzer finden viele Fehler und Mängel, die noch nicht auf der Liste stehen. Alan erklärt, dies sei keine Überraschung. Schließlich handele es sich um eine Vorab-Version, in der man Fehler erwartet hätte.
Etwa zwei Monate später stellt das Team die Produktiv-Version fertig. Das Programm besteht aus etwa 2.500 Zeilen Code. Beim Austesten scheint es den größten Teil der Spezifikation zu erfüllen. Ein oder zwei Features wurden ausgelassen, und das Programm ist sehr penibel, was das Format der Eingabedaten angeht. Doch die Firma entscheidet, das Programm einzusetzen. Sie werden ihr Dateneingabe-Personal darin schulen, die Daten in dem benötigten strengen Format einzugeben. Das Programm wird an einige Programmierer zur Wartung übergeben, um die fehlenden Features irgendwann einmal nachzurüsten.
Zunächst war Charles' Vorgesetzter beeindruckt. Doch als er den Quellcode durchlas, merkte er, dass das Projekt in Wahrheit viel einfacher war, als er ursprünglich dachte. Es schien nun offensichtlich, dass dies selbst für einen Programmier-Anfänger keine große Herausforderung war.
Charles produzierte 5 Zeilen Code pro Tag. Das liegt vielleicht etwas über dem Durchschnitt, doch angesichts der Einfachheit des Programms war es nichts Außergewöhnliches. Zudem dachte der Vorgesetzte an die zwei Monate des Faulenzens.
Bei seiner nächsten Gehaltsrevision erhielt Charles eine Gehaltserhöhung, die ungefähr der halben Inflationsrate über dem Zeitraum entsprach. Er erhielt keine Beförderung. Nach etwa einem Jahr hatte er keine Lust mehr und verließ Consolidated.
Bei Automated wurde Alan für die pünktliche Fertigstellung seines Projektes beglückwünscht. Sein Vorgesetzter inspizierte das Programm. Während er ein paar Minuten durchblätterte, sah er, dass die Firmenstandards über strukturierte Programmierung eingehalten wurden. Jedoch gab er schnell den Versuch auf, das Programm tatsächlich zu lesen; es erschien ihm gänzlich unverständlich. Er merkte, dass das Projekt in Wahrheit viel komplizierter war, als er ursprünglich dachte, und er gratulierte Alan nochmals für seine großartige Leistung.
Das Team produzierte 3 Zeilen Code je Programmierer pro Tag. Das lag im Durchschnitt, doch angesichts der Komplexität des Problems konnte dies als außergewöhnlich betrachtet werden. Alan erhielt eine kräftige Gehaltserhöhung und wurde als Belohnung für seine Leistung zum System-Analytiker befördert.