© iStockphoto.com/P2007, © S&S Media
Olis bunte Welt der IT

Olis bunte Welt der IT


Verantwortung teilen ist gut. Wer mag schon die ganze Verantwortung tragen, wenn die halbe es auch tut? Auch technisch macht das Teilen von Verantwortung und den damit zusammenhängenden Zuständigkeiten fast immer Sinn. Aber in der Praxis sind die notwendigen Schritte nicht immer so einfach.

Ich erinnere mich zum Beispiel lebhaft an die Einführung von XAML als Seitenbeschreibungssprache für grafische Bedienoberflächen. Besonders von Microsoft wurde damals eine Aufteilung in den Vordergrund gestellt, die jeder Programmierer zu schätzen wissen sollte: Die visuelle Erscheinung einer Anwendung sollte fortan einem Designer überlassen sein. Der Programmierer sollte sich nur noch um die technischen Hintergründe kümmern und einem Designer vertrauen, das Werk in eine ästhetisch angenehme Form zu bringen.

Nun fand ich persönlich diese Idee sofort richtig gut. Ich spare als Entwickler viel Zeit, wenn ich mich nicht um visuelle Fragen kümmern muss, und als Berater hatte ich auch die Hoffnung, in Zukunft wesentlich weniger grün und magenta gestylte Formulare zu Gesicht zu bekommen, in denen es Editoren für Primärschlüssel und elf Ebenen verschachtelter Gruppen gibt. Natürlich stand dem letztlich ein praktisches Problem im Wege: Die meisten Entwicklungsteams beschäftigten bisher keinen Designer.

Interessant war aber auch, welche Gegenwehr von Seiten der Entwickler zu beobachten war. Eigentlich gab es wesentlich wichtigere Pläne zur Verantwortungsteilung in XAML-basierten Anwendungen, zum Beispiel in Bezug auf die neuen mächtigen Features der Datenbindung und der Patterns, die sich somit anboten. Selbst heute noch basieren viele WPF-Anwendungen nicht auf MVVM oder vergleichbaren Konzepten, und auch Ressourcen werden oft nicht so genutzt, wie es wünschenswert wäre.

Der Wert der Erfahrung

Nun soll dies keine Tirade sein, sondern nur ein objektiver Blick auf die Schwierigkeiten, die wir alle haben, wenn ein Muster, auf das wir lange Zeit gesetzt haben, sich ändert. Sicher gibt es oft praktische Gründe, warum die Neuheiten sich nicht sofort für bestehende Anwendungen anbieten oder für neue Projekte gar zu umständlich erscheinen. Aber vor allem möchten wir gern an den Erfahrungen der Vergangenheit festhalten und ein neuer Blickwinkel erscheint zunächst oft bedrohlich.

Über diesen Sachverhalt habe ich kürzlich nachgedacht, als ich einige Arbeit im Bereich der Patterns CQRS und Event Sourcing getan habe. Beide Patterns werden, wie ich bei meiner Recherche festgestellt habe, oft...

Neugierig geworden?

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang