... Organisationsentwicklung,, Aikido, Strategie und alles was mir sonst noch einfällt und nicht in mein englisches Blog passt...

Mittwoch, 22. August 2007

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