Chaos und starke Typisierung

Phillip schrieb vor kurzem in seinem Blog über die Angst des Menschen an sich (und des Menschen in der Softwareentwicklung im besonderen) vor dem Chaos.

Besonders die von ihm erwähnten Mottos verdienen einen Kommentar

Mottos der letzten Jahre wie “Alles ist ein Dokument!”, “Alles ist ein CORBA-Objekt”, “Jede Ressource kann direkt über HTTP abgerufen werden” oder “Alle Systeme werden über EJB integriert” lassen erahnen, wie stark der Wunsch nach Ordnung ist.
Interessanterweise nannte mein Physiklehrer den Zustand, in dem alles gleich ist, Chaos. Er sagte, in diesem kann man nichts auseinander halten.

Spontan musste ich dabei an die verbreitete Abneigung gegenüber Sprachen mit Laufzeittypisiserung denken, die heute bei vielen Entwicklern und Entscheidern in der Softwareentwicklung verbreitet ist.

Irgendwie ist mein Kommentar dann doch etwas länger geworden...

Der - nur allzu verbreitete - Wunsch danach, keine falsche Entscheidung zu treffen, führt gerade in unserer Branche (also der Informmationsverarbeitung) zu den erstaunlichsten Auswüchsen. Ein Beispiel dafür sind die Typsysteme. Damit der Entwickler möglichst wenig falsch machen kann, soll möglichst früh durch den Rechner erkannt werden, ob er "alles richtig" gemacht hat. Also entwerfen wir (oder zumindest ein Teil von uns) munter Entwicklungsumgebungen, die möglichst restriktiv in dem sind, was der Entwickler machen kann. Und mit schöner Regelmäßigkeit sind die erfolgreichsten Erweiterungen für diese Systeme, solche, die darauf basieren, diese Beschränkung zu umgehen. (* Konkretes Beispiele: siehe Fußnote).

Zudem neigen viele der Entwickler, die ich kenne dazu, "erstmal eine allgemeine Lösung zu erstellen" damit "der normale Entwickler" auch mit "der Komplexität Umgehen kann" - erstaunlicher weise kenne ich kaum einen "normalen Entwickler", der froh ist die "allgemeinen Lösungen" zu haben - im Gegenteil: je größer die Entfernung zwischen Entscheider (oder demjenigen, der die "allgemeine Lösung" entworfen hat) und Realisierer ist, umso mehr wird nach Wegen gesucht, trotz der starren Vorgabe erfolgreich zu sein - und meistens funktioniert das auch.

Fazit meines kurzen Kommentars:
Klare Vorgaben sind nicht per se schlecht - ganz im Gegenteil. Aber:

Alle Vorgaben in der Softwareentwicklung, die mit Alle beginnen neigen dazu, kontraproduktiv zu sein.

Cheerio
_MM_

*) Hier ein kleines Beispiel aus dem Java-Umfeld:
Für diese stark typisierte Sprache ist der Kern einiger der erfolgreicheren Frameworks zum großen Teil mit der Umgehung der Typisierung befasst: JUnit, Hibernate, Spring, Struts

SOA für Manager - Was passiert mit mir?

Bin ich zum SOA-Evangelisten geworden?
Nachdem ich bereits im letzten Jahr einen SOA Beitrag für "SOA-Expertenwissen" geschrieben habe, bin ich nun schon wieder dabei, etwas über serviceorientierte Architekturen zu schreiben.
Für den Management-Lehrgang "Service-orientierte Architekturen" des Euroforums arbeite ich derzeit an der Lektion 4 (Genaueres ist im Flyer zu finden).
Ich hoffe, meine Beiträge machen deutlich, dass für den Aufbau einer SOA (und dieser Begriff scheint wirklich derzeit in Großunternehmen nicht mehr zu umgehen zu sein) methodisches Vorgehen und teilweise jahrzehnte alte Techniken durchaus noch ihre Daseinsberechtigung haben. Nur ihr Kontext hat sich gewandelt und muss im Rahmen von serviceorientierten Vorhaben besonders berücksichtigt werden.
Meine Antwort auf die Frage "Bin ich zum SOA-Evangelisten geworden?" lautet also: "Nein, aber wenn es schon einen neuen, mächtigen Ansatz gibt, grundlegende Konzepte wie lose Kopplung und hohe Kohesion zu etablieren, dann sollte man ihn auch unterstützen."
_MM_

iPod neu definiert: Der iPott

Endlich gibt es in Köln den stilechten Kaffe für den Multimediafreund von Heute. Das Holtmanns in Köln bietet jetzt den iPott an.

Test der Fußzeile

... Da blogger leider keine komfortable Möglichkeit bietet, Feed-Reader oder Abrufe zu zählen, versuche ich es mal mit einer Grafik in der Fußzeile - schliesslich machen macupdate und co das ebenso ...

Und es scheint zu funktionieren ...

Noch ein Blog?

Wozu brauche ich eigentlich noch ein Blog, wo ich doch schon in meinem englischen Blog kaum zum regelmäßigen posten komme?
Ganz einfach: viele der Sachen, die ich eigentlich unter agile-aspects posten würde sind einfach nur von lokalem Interesse und international überhaupt nicht relevant - deshalb schreibe ich dort weniger, als ich es tun könnte - mal sehen, ob ich hier mehr dazu komme auch mal Kleinigkeiten zu posten.
_MM_

Warum Shu-Ha-Ri?

Obwohl ich selber aktiv Aikido betreibe (und dort wird das Shu-Ha-Ri besonders oft zitiert) hat mich nicht diese Kampfkunst zu dem Namen des Blogs verleitet, sondern ein Buch von Alistair Cockburn, in dem er dieses Prinzip auf Softwareentwicklung erweitert.
Was steckt aber hinter diesem Prinzip?
Nichts weiter, als der "Weg" zum Erlernen. Zum Erlernen von was? Eigentlich zum Erlernen der (japanischen) Kampfkünste, aber ebenso zum Erlernen aller "Fertigkeiten" - das wird auch dadurch deutlich, dass einer der Ursprünge des Shu-Ha-Ri Konzeptes bei der Tee-Zeremonie zu finden ist.
Eine englische Erläuterung ist bei Wikipedia zu finden, kurz skizziert geht es um folgendes:
Das Lernen wird in drei Phasen betrachtet. In der ersten Phase (Shu, 守, grob übersetzt: beschützen aber auch gehorchen) werden die Techniken "nach dem Buch" ausgeführt und im eigentlichen Sinne erlernt. In der zweiten Phase (Ha, 破, grob übersetzt: abschweifen, mit etwas brechen) werden die Techniken und ihre Grenzen erprobt um dann in der dritten Phase (Ri, 離, grob übersetzt: [etwas] verlassen, sich trennen) neu kombiniert und vom früheren Schüler selber erweitert zu werden.

_MM_