Es gibt so eine Art Qualitätskurve, auf der man Software ansiedeln kann. Am einen Ende findet man Werkzeuge für den Einmalgebrauch, schnell zusammengeschustert ohne Rücksicht auf Stil und Speicherlecks, Hauptsache, die Aufgabe läuft irgendwie durch. Danach kommen eigene Tools für den Hausgebrauch, dann vielleicht Software für Einzelkunden oder Unternehmenssoftware, später sog. "Shrinkwrap", also massentauglicher Kram der im Mediamarkt in den Regalen steht und ganz am Ende Firmware und Konsolenspiele. Wenn man für das jeweilige Produkt einen festen Zeitaufwand zugrunde legt wird man feststellen, daß sich die Aufgabenanteile für unterschiedliche Tätigkeiten wie Konzeption, Implementierung und Test auch entlang dieser Kurve verschieben.

Das fiel mir neulich bei einem Gespräch mit einem Kollegen auf, bei dem es darum ging, daß wir nicht sicher wissen, welche Teile des Codes überhaupt verwendet werden bzw. welche Teile der Anwendung der Kunde überhaupt nutzt. Wenn wir jetzt Computerspiele entwickeln würden, hätten wir da ein großes Problem. Tun wir aber nicht. Und das beste: Wir haben nicht einmal Zeit, es herauszufinden. Tests auf dem Niveau von Shrinkwrap würden bei uns Bugs und Inkonsistenzen in enormer Anzahl zutage fördern. Aber es gibt keinen Vorteil, wenn viel Zeit verbraucht wird und der betreffende Bereich der Anwendung nie vom Kunden ausgeführt wird. Ein anderes Beispiel ist das Refakturieren. Damit bezeichnet man das Umschreiben von größeren Programmteilen mit dem Ziel, eine Vereinfachung, Verbesserung und in vielen Fällen auch quantitative Verringerung des Programmcodes herbeizuführen. Die Vorteile bleiben zwar, dennoch bringt eine Refakturierung in unserem Bereich mehrere Nachteile mit sich:

• Der refakturierte Code muß erneut getestet werden
• Es ist schwer sicherzustellen, daß durch die Änderungen keine unerwarteten Nebenwirkungen auftreten
• Die Änderungen müssen an die Kollegen kommuniziert werden
• Durch die enorme Menge vorhandenen Codes sind i.d.R. fast immer größere Änderungen erforderlich. Der dafür benötigte Zeitaufwand kann nicht immer fakturiert werden. Falsch. Kann eigentlich nie fakturiert werden.

Ein guter Freund von mir ist ein regelrechter Code-Ästhet. Nichts soll redundant sein, alles effektiv und glatt gebügelt. Er hätte mit dem Kram hier nicht viel Freude.
Worauf ich hinaus will: Man kann zwar denselben Beruf haben, aber seinen Tag trotzdem fast komplett mit andere Dingen verbringen.