Wollen Ihre EntwicklerInnen immer das Neueste in ihren Projekten verwenden? Setzen Sie Go ein? Haskell? Mercury?
“Das ist die nächste große Sache!” vs. “Das wird sich nicht durchsetzen!” – Bei neuen Technologien ist es nicht so einfach, frühzeitig auf das richtige Pferd zu setzen. Wenn man natürlich nur das macht, was alle anderen auch tun, ist es simpel: Nobody gets fired for buying IBM.
Wenn man aber einen Wettbewerbsvorteil durch Technologie haben und evtl. auch noch Software-Talente an sich binden will, dann gilt es, neue Technologien frühzeitig einzusetzen. Auf der anderen Seite kann es sehr wehtun, wenn man eine Komponente einsetzt, die später von niemandem unterstützt wird. Ich habe mir da mal an einer objektbasierten Datenbank die Finger verbrannt. Sie war technologisch super, aber es gab keine Leute, die sich damit auskannten. Ähnlich erging es mir mit einem Web-Framework in Smalltalk, das leider über den Exoten-Status nie hinauskam. Während man für die Etablierten alle möglichen Komponenten im Netz finden konnte, musste man hier sehr viel alleine machen. Bei Problemen half die alte Taktik “einfach die Fehlermeldung googeln” nur selten. Und ich glaube, diejenigen, die die Applikation nach mir weitergeführt haben, haben ganz schön geflucht ob der exotischen Programmiersprache.
Nach ein paar ähnlichen Erlebnissen habe ich für mich einen Filter entwickelt, um neue Technologien auszuwählen.
Wonach kann man sich da richten? Alles selbst evaluieren? Das macht zwar (Einigen) Spaß, aber selbst gute Technologien sterben manchmal schnell wieder. Unterstützung durch ein großes Unternehmen? Da hab ich mal ein gutes, dickes Buch über Jini gekauft, von Sun Microsystems angekündigt als die Zukunft bei verteilten Systemen. Technologisch brilliant, aber man hat nie wieder was davon gehört. Ich habe dann die Regel aufgestellt:
Bevor wir hier eine neue Technologie einsetzen, muss es darüber mindestens zwei Bücher von renommierten Verlagen geben.
Ein einzelnes Buch (vielleicht noch vom Autor des Frameworks selbst publiziert) reicht also nicht. Ich mache mir mit dieser Regel das Technologieradar von O’Reilly und anderen zunutze, die haben das Trendwatching perfektioniert. Das Zwei-Bücher-Kriterium ordnet uns im Technologie-Lebenszyklus ein, auf dem Spektrum zwischen “brandneu und vielleicht nächstes Jahr schon gestorben” und “so etabliert, dass man damit keinen Wettbewerbsvorteil mehr hat”.
Als Test wende ich den Filter mal auf einige Beispiele an. Zu jeder Technologie habe ich herausgesucht, ab wann es ggf. zwei ernstzunehmende Bücher gab.
Infractructure Automation, DevOps:
Programmiersprachen:
Front End, JavaScript:
Je nachdem, wo Sie auf dem Spektrum zwischen brandneu und etabliert stehen wollen, können Sie das Zwei-Bücher-Kriterium natürlich abwandeln. Zum Beispiel können Sie große Konferenzen heranziehen (so hatte eine Kubernetes-Konferenz 2018 in Nordamerika 8000 TeilnehmerInnen), oder Sie warten, bis ein Buch zum Thema in der Serie “For Dummies” herauskommt (C# seit 2001, Ruby on Rails seit 2007, jQuery seit 2010).
Matthias Berth