Raten Sie mal: Welches von Menschen geschaffene Produkt altert und verschleißt nicht? Nein, es ist nicht der VW-Käfer. Auch eine LED haucht irgendwann ihr sparsames Leben aus, genauso wie die 100jährige Glühbirne. Es ist – Software. „Aber ich brauche doch alle paar Jahre einen neuen Computer!“, werden Sie jetzt erwidern. Stimmt, aber das liegt nicht am Verschleiß der Software.
Ein Computerprogramm verändert sich nicht durch die Benutzung, und es wird auch nicht schlechter durch Nicht-Benutzung. Natürlich enthält die meiste Software Fehler – aber die entstehen nicht durch die Benutzung oder durch Verschleiß, sondern sie sind von Anfang an enthalten und treten früher oder später auf, mit etwas Glück aber auch nie.
Software wäre also geradezu prädestiniert für eine möglichst lange Lebensdauer, würden nicht ständig wachsende Ansprüche an Datenmengen und neue Funktionen eine Änderung und Weiterentwicklung erfordern – und damit die Gefahr neuer Fehler mit sich bringen.
Wir Software-Architekten und Entwicklungsingenieure können natürlich einiges dafür tun, um unseren Produkten ein langes Leben einzuhauchen.
An vorderster Stelle steht dabei sicherlich die Qualität. Niemand arbeitet gern mit einem fehlerhaften Programm. Mindestens ebenso wichtig sind Ergonomie und eine ansprechende optische Gestaltung der Bedienoberfläche. Ein Programm, das den Anwender bei seiner täglichen Arbeit optimal unterstützt, wird länger und lieber benutzt als eine Software, deren Schrift schlecht lesbar ist oder bei der ich die gesuchten Informationen immer erst auf der 3. oder 4. angeklickten Seite finde.
Mindestens ebenso wichtig sind die interne Struktur eines Programms, die Menge und Verwaltung der gespeicherten Daten und die Konzeption von Schnittstellen. Das Weglassen von Programmiertricks und ein modularer Aufbau helfen, Fehler zu vermeiden. Daten sollten nicht zu stark komprimiert werden. Und wenn bei Schnittstellen zum Betriebssystem und zu anderen Programmen Standards eingehalten werden, sind wenig Probleme mit der Kompatibilität zu neuen Versionen zu erwarten.
Besondere Bedeutung haben diese Punkte bei der Erstellung eines Programms zur Archivierung von Daten. Diese sollen auch nach Jahren oder Jahrzehnten noch lesbar sein. Der technische Fortschritt und die natürliche Alterung der Datenträger machen es erforderlich, die archivierten Dateien in regelmäßigen Abständen auf neue und aktuelle Datenträger zu überspielen und immer mindestens zwei Kopien an getrennten Orten zu lagern. Für die Suche wichtiger Informationen über die archivierten Daten müssen diese auch unabhängig von den Archiv-Datenträgern verfügbar sein, um nur ein paar Anforderungen aufzuzählen.
Unter solchen Voraussetzungen kann ein Programm ein „biblisches“ Alter von über 20 Jahren erreichen. Ein Beispiel dafür ist AUTARCH, ein Archivierungssystem des Mainframe-Betriebssystems BS2000 von Siemens. Wer weiß, was aus AUTARCH geworden wäre, wenn unser Auftraggeber IBM geheißen hätte und das System OS/390?