Montag, März 19, 2007

Scrum ist nicht Agil?

Es ist ein interessanter Blog-Artikel mit dem Titel "Scrum is not Agile" aufgetaucht. In dem Artikel wird nicht argumentiert, dass Scrum unagil sein. Es wird stattdessen argumentiert, dass die Gleichsetzung Scrum==Agil nicht stimmt, weil agil eben mehr ist als Scrum.
Scrum biete agiles Management. Man bräuchte aber auch aktive Kundeneinbindung, iteratives Vorgehen (inkl. Incremental Design) und selbstorganisierende Teams. Das ist alles auch mit Scrum möglich, aber Scrum gibt keine konkreten Hinweise, was jeweils zu tun ist.
XP deckt immerhin noch das iterative Vorgehen / inkrementelles Design ab.
Für die aktive Kundeneinbindung und die selbstorganisierenden Teams scheint aber noch was zu fehlen.

Post bewerten

Transaktionslose Anwendungsentwicklung

Ich selbst bin kein großer Freund verteilter Transaktionen. Sie bergen meiner Meinung nach eine Komplexität, die nur die wenigsten Entwickler beherrschen.
Daher halte ich es auch für sehr schade, dass sich in breiten Kreisen die Ansicht durchgesetzt hat, dass man auf jeden Fall verteilte Transaktionen braucht, wenn man mehrere Datenbanken oder zu integrierende Systeme hat.
Dass das keineswegs so ist, beschreibt Martin Fowler am Beispiel eBay.

Post bewerten

Montag, März 12, 2007

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

Sonntag, März 11, 2007

Zweite Auflage des Hibernate-Buches erschienen

Vor kurzem haben Robert Beeger, Arno Haase, Sebastian Sanitz und meine Wenigkeit die zweite Auflage unserer Hibernate-Buches fertig gestellt. Es ist jetzt im dpunkt-Verlag erschienen und man kann es kaufen.


Neben ein paar kleineren Verbesserungen haben wir das Buch auf Hibernate 3.2 aktualisiert, das Java Persistence API (EJB 3) ergänzt und die Integration von Hibernate in Spring beschrieben.

Post bewerten

Dienstag, März 06, 2007

Buchtipp: Practical Common Lisp

Peter Seibel führt mit Practical Common Lisp anhand praktischer Beispiele (Unit-Testing, MP3-Dateiparsing, Web-Anwendungen etc.) in Common Lisp ein und zeigt damit eindrucksvoll, dass Common Lisp keineswegs auf künstliche Intelligenz oder funktionale Programmierung beschränkt ist.
Das Buch gehört zu den sehr wenigen IT-Büchern, bei denen das Lesen Spaß macht.

Auch wenn man selbst nicht mit Common Lisp arbeiten wird, öffnet das Buch ganz neue Perspektiven. Es ist schon erstaunlich, wie weit Common Lisp seiner Zeit voraus war und noch ist. Ich kenne keine andere Programmiersprache, die so mächtige Features hat wie Common Lisp.

Das Macro-System (nicht zu vergleichen mit dem C-Macros) erlaubt die Definition eigener Sprachen in Common Lisp - ein Ansatz, der heute als DSL (Domain Specific Language) bekannt ist und mit vergleichsweise wahnsinnig hohem Aufwand und Code-Generierung betrieben wird.

So kann man eigentlich bei jedem Feature anderer Programmiersprachen sagen: "Das hat Common Lisp auch, nur mächtiger und flexibler." Da stimmt es mich schon etwas traurig, dass sich Common Lisp nicht in der Breite durchgesetzt hat und man heute noch mit vergleichsweisen Krücken unterwegs ist.

Da drängt sich natürlich die Frage auf, warum wir dann nicht einfach alle in Common Lisp programmieren. Eine Antwort gibt Paul Graham.

Dem habe ich noch hinzuzufügen, dass Common Lisp zwar unbestreitbar sehr mächtig ist, aber auf eigenartige Weise etwas schief zusammengesetzt wirkt. Das ist aber kein wirklich starkes Argument, weil mit Scheme und NewLisp weitere Lisp-Dialekte zur Verfügung stehen.

Post bewerten