An jedem Software-Projekt ist eine Unmenge von Leuten beteiligt die die unterschiedlichsten Rollen wahrnehmen. Da gibt es Projektleiter, Fachspezialisten, Tester, Architekten, Designer und was sonst noch alles. Je größer das Projekt, desto größer die Zahl der Beteiligten. Und wenn die Software in den Betrieb geht kommen noch mehr Leute und noch mehr Rollen hinzu. Software ist — heute mehr denn je — ein Team-Produkt.

Wer in obiger Aufzählung nicht erwähnt wurde, das sind die Coder, die Programmierer oder Software-Ingenieure. Diejenigen, die — in der Sprache der Machine — das formulieren, was die Maschine später zu tun hat. Ihnen kommt eine einzigartige Bedeutung zu. Denn nüchtern betrachtet ist ihre Arbeit das einzige, was am Ende übrig bleibt und tatsächlich „etwas tut“ wenn die Software live geht.

Das bedeutet nicht, daß der Rest des Teams überflüssig wäre — ganz im Gegenteil. Erst die gemeinsame Anstrengung macht den Erfolg des Projektes überhaupt erst möglich. Der Projekt-Plan ist wichtig um das Projekt durchzuführen, verschwindet aber wenn das Projekt abgeschlossen ist. Die Arbeit der Tester ist ein wichtiger Bestandteil des Entwicklungsprozesses, aber am Ende läuft nur noch der Code; von den Testläufen ist am Ende nur noch das Ergebnis übrig.

Es ist so ähnlich wie bei einer militärischen Operation. Von vier eingesetzten Soldaten werden drei für Transport, Versorgung und Unterstützung der Truppen — von der Verpflegung bis zur Flugabwehr — benötigt. Der eigentlichen Kampf — Mann gegen Mann — wird in der ganzen Kette von einer erstaunlich kleinen Gruppe geführt. Alle Beteiligten sind wichtig, alle Beteiligten setzen sich sich Lebensgefahr aus, aber die Schlacht wird letztenendes von den Kampftruppen entschieden.

Wenn dann die Anwendung im Betrieb ist, das Team sich anderen Projekten widmet und in der Software ein Problem auftritt, dann zeigt sich wie gut der Coder tatsächlich gearbeitet hat. Denn oft genug sind diejenigen die die Anwendunng betreuen nicht die gleichen wie die die sie gebaut haben. Dann zeigt sich, ob der Code sauber entwickelt oder einfach nur heruntergerotzt wurde.

Jeder im Projekt muß solide Arbeit leisten wenn das Endprodukt erfolgreich sein soll. Aber wenn das was der Coder baut nur gerade eben das tut was die Anforderungen verlangen, schläft in der Anwendung eine Bombe die mit Sicherheit dann hochgeht, wenn man es am wenigsten gebrauchen kann. Wenn dann Fragen auftauchen wie „Was macht eigentlich diese Funktion?“ oder „Was geschieht, wenn man diesen Wert ändert?“, dann zahlt man doppelt und dreifach was man im Projekt an der Entwicklung gespart hat.