Manchmal habe ich das Gefühl, dass die Berechtigung der einschlägigen Fachmagazine für Softwareentwicklung einzig auf der stetigen Flut neuer Frameworks und Buzzwords basiert. In regelmäßigem Rythmus liefern die Titelseiten die Namen neuer Techniken, Prinzipien oder Frameworks.
Selbstverständlich ist es zu begrüßen, dass es für spezielle Probleme auch die richtigen Werkzeuge gibt. Dumm nur, wenn es für das immer selbe Problem beliebig viele Alternativen gibt. Dies gilt z.B. für Java MVC Frameworks im Web oder Internettechnologien im Allgemeinen. Man kommt sich vor wie am Marmeladenregal im Supermarkt: da stehen so viele verschiedene Sorten zur Auswahl, dass man die “richtige” gar nicht mehr auswählen kann. Im Gegensatz zur Frühstücksmarmelade – diese kann maximal die Laune des Essenden verbessern – ist die Entscheidung für eine Technologie jedoch entscheidend für den Erfolg oder Misserfolg eines Projektes oder sogar eines Unternehmens.
Gerade haben wir wieder ein Projekt auf dem Tisch, in dem das CMS “Drupal” von einem Entwickler dahingehend “angepasst” wurde, dass damit Content für mobile Endgeräte über den Dienst von netBisquit verwaltet werden kann. Dumm nur, dass zwischen den Wünschen des Kunden, den zugrundeliegenden Prinzipien von Drupal und den Anforderungen von netBisquit einige interessante Lücken entstehen. Zudem passt Dupal überhaupt nicht in die ansonsten javaorientierte IT-Struktur des Kunden – und bei Gesprächen mit einigen CMS Kennern ergibt es sich, dass Drupal zwar toll sei, seine Stärke aber bei Community-Featurs besitze (die überhauptnicht benötigt werden). Wie kann es also dazu kommen, dass man versucht hat, auf Biegen und Brechen die Anforderungen auf diese Weise umzusetzen?
Ich vermute die Antwort lautet: weil der Softwareentwickler nichts anderes kannte. Die wichtigste und gleichzeitig die am schwierigsten zu erlangende Qualifikation des Entwicklers sollte es sein, technische Empfehlungen aussprechen zu können. Denn dass ein (untechnischer) Kunde im Dickicht der angebotenen Technologien den Überblick hat ist sicher nicht der Fall – er ist angewiesen auf die Empfehlung des Softwareentwicklers. Und dann passiert der Kardinalfehler, wenn der Entwickler einfach genau das empfiehlt, was er am besten kennt – aber eben nicht, weil es am besten geeignet ist! Der Nicht-Techniker ist dann sowieso darauf angewiesen dem “Experten” zu glauben – wie die Hausfrau dem Kfzmechaniker, der ihr erklärt, warum die Fehlfunktion des Fensterhebers die Komplettlackierung des Autos zur Folge hat.
Werkzeuge funktionieren immer in dem Umfeld gut für das sie gebaut worden sind. Sicher kann man eine Kreuzschlitzschraube auch mit einem Schlitzschraubendreher herausbekommen – oder den Nagel mit einem Bügeleisen reinhauen. Aber so richtig gut geht das nicht. In der Softwareentwicklung bekommt man die Rechnung dann erst nach einer Weile, wenn man Anforderungen nur noch mit großen Kompromissen umsetzen kann oder nur ein Entwickler von zehn das Spezialknowhow für die Lösung besitzt – dann ist das Projekt gefährdet.
Mögliche Fragestellungen zur Überprüfung einer technischen Entscheidung sind z.B.
- Was ist Ziel und Vision des Projektes?
- Wofür ist mein gewähltes Framework gemacht? Passt das mit dem Projektinhalt zusammen?
- Habe ich genügend Know-How – und wenn nicht: woher bekomme ich welches am Markt?
- Passt die Technologie zu meinen anderen Projekten?
- Wie verbreitet und ausgereift ist die Technik?
- Gibt es ähnliche Implementierungen bei Anderen?
- Wie viele Bücher gibt es bei Amazon dazu?
- Wie beliebt ist die Technik im GULP Projektmarktindex?
Was man auf keinen Fall braucht ist die beinahe religiöse Neigung, mit der einige Entwickler den favorisierten technischen Lösungen auf Gedeih und Verderb die Treue halten.
In diesem Sinne wünsche ich Aufgeschlossenheit, Objektivität und ein glückliches Händchen bei der nächsten Technologieentscheidung!
Es handelt sich um das Buch “Payback” von Frank Schirrmacher. Erschienen im Karl Blessing Verlag (16. November 2009).
]