Die Mächtigkeit der Gleichförmigkeit

An verschiedenen Stellen (z.B. erst vor ein paar Tagen hier) habe ich immer mal wieder behauptet, das Cobol-System, an dem ich als Student mitgearbeitet habe, sei besser strukturiert gewesen als viele der C++- und Java-Systeme, denen ich danach begegnet bin. Diese Aussage hat bei einigen Lesern zu Unverständnis bis Entsetzen geführt. Grund genug, der Sache einmal auf den Grund zu gehen.

Gilt diese Aussage generell für Cobol-Systeme?
Nein, definitiv nicht. Ich habe auch einige Cobol-Systeme gesehen, die deutlich schlechter strukturiert waren als viele Java-Systeme.

Liegt es daran, dass an die Java-Systeme viel höhere Anforderungen gestellt wurden also an die Cobol-Systeme?
Nein. Viele der Java-Systeme unterschieden sich nur dadurch von den Cobol-Systemen, dass sie eine grafische Benutzungsoberfläche mit Swing hatten. Und die ist in Java eher leichter zu programmieren als in Cobol alles von Hand für zeichenbasierte Oberflächen zu codieren. Und selbst wenn Swing die Sache erschwert hätte, hätte das nur Auswirkungen auf die oberflächennahen Teile des Systems haben dürfen und nicht auf die Gesamtstruktur.

Liegt es daran, dass das Cobol-System besonders klein und übersichtlich war?
Nein. Es handelte sich um eine komplette Warenwirtschaft mit Lagerverwaltung und Produktion. Das System ist von ca. 10 Leuten über 10 Jahre lang weiterentwickelt worden.

Liegt es daran, dass am Cobol-System besonders gut ausgebildete Entwickler gearbeitet haben?
Nein. Es gab kaum ausgebildete Informatiker im Team. Einer der Entwickler war vorher Koch und ein anderer Steuerfachgehilfe.

Woran lag es denn dann?
Das System hatte eine einfache Musterarchitektur, die sich durch das ganze System zog. Stammdatenprogramme, Dialog-Programme, Auswahl-Dialoge, Batch-Programme, Druck-Jobs wurden nach dem immer gleichen Schema entwickelt, dass über die Jahre entstanden ist.

Damit war jedem Entwickler bei einer neuen Anforderung sofort klar, wo welche Änderungen notwendig waren und auch, wie teuer diese werden würden. Schätzungen, die stark von den tatsächlichen Aufwänden abwichen, habe ich im Projekt nie erlebt.

Dabei sind natürlich unglaublich viele Redundanzen entstanden. Wenn man ein neues Stammdatenprogramm schreiben wollte, hat man sich ein existierendes Stammdatenprogramm geschnappt und dieses angepasst. Das war Wiederverwendung durch Copy&Paste in Reinkultur.
Und trotzdem hat es funktioniert. Dabei sind sich alle einig, dass das eigentlich unmöglich ist.

Ich glaube, der Grund ist in der Gleichförmigkeit zu suchen, die das System hatte. Redundanzen sind gar nicht so schlimm, wenn sie jedem klar sind. Wenn ich für das Hinzufügen eines Feldes 100 Stellen anpassen muss, ist das halb so wild, wenn mir

1. klar ist, wo ich die 100 Stellen im Code finde und
   
2. jede Änderung mechanisch durchführbar ist, gerade wg. der Gleichförmigkeit des Codes.

Steht so eine Änderung an, ist diese zwar langweilig, aber nicht aufwändig. 100 gleichförmige Änderungen in bekanntem Code macht man in 2-4 Stunden.

Für diese Änderungen ist neben der Gleichförmigkeit eine andere Eigenschaft wichtig: Minimale Abhängigkeiten. Wenn niemand von den geänderten Code-Stellen abhängt, besteht nur geringe Gefahr, durch die Änderungen etwas kaputt zu machen. Außerdem gibt es das Risiko des Ripple-Effekts nichts: Die Änderung bringt weitere Änderungen in abhängigen Code nach sich, die wieder Änderungen in abhängigem Code nach sich ziehen...

Das führt mich zu der These, dass die bessere Cobol-Struktur sich an nur einer Eigenschaft festmacht: Es gab in dem Cobol-System weniger und klarer definierte Abhängigkeiten als in vielen Java-Systemen.

Diese Eigenschaft hat man sich erkauft durch Redundanzen (geht in Cobol auch nicht wirklich anders). Offensichtlich konnte man mit den Redundanzen aufgrund der Gleichförmigkeit besser umgehen als mit Java-Strukturen, die weniger Redundanzen aber dafür größere Abhängigkeiten aufweisen.

Sollten wir also zu Cobol zurück? Auf gar keinen Fall!

Wir sollten uns aber bewusster werden, wie gefährlich Abhängigkeiten zwischen Systemteilen werden können und wie leicht man sich in OO-Programmiersprachen unentwirrbare Abhängigkeitsgeflechte schafft. Vielleicht sollten wir eher einmal gleichförmige Redundanzen zulassen, um damit Abhängigkeiten zu reduzieren?

Post bewerten