Der goldene Hammer als das einzig wahre Werkzeug
Nichts anderes im Berufsleben hat mich von Zeit zu Zeit mit so einer Vehemenz überrascht und über Wochen und manchmal gar Monate von der vollen Konzentration auf die Projektarbeit abgehalten, wie ein fast schon ideologisch geprägter Glauben von Entscheidern auf Dienstleister- oder Kundenseite, dass ein bestimmter Technologieansatz, eine ganz spezielle Software, ein ausgewähltes Produkt oder ein ausgesuchter Hersteller genau die richtige und einzig wahre Lösung für die Projektanforderungen sei.
Das Anti-Pattern des goldenen Hammers
Ich habe mich für die Begrifflichkeit des „Golden Hammer“ für die Klassifizierung dieses Phänomens entschieden. Die als „Anti-Pattern“ bezeichneten Verhaltensweisen für schädliche oder nachteilige Ansätze für ein Projekt oder eine Organisation kennen eine Reihe von passenden Formulierungen, je nach dahinter stehender Motivation. Am nächsten kommt jene des goldenen Hammers in Anlehnung an den amerikanischen Psychologen Abraham Maslow, der annahm, dass wenn man nur ein Werkzeug (Hammer) besitzt und gut kennt, alles damit lösen möchte. Im Fall eines Hammers bedeutet dies, jedes und alles als einen Nagel zu betrachten und zu behandeln.
In der Datenbank programmierte Webseiten
In den ersten Jahren der Online-Projekte gab es in IT-Firmen, die auch andere Technologien beherrschten, noch Skepsis gegenüber Programmiersprachen wie Java und PHP. Diese Skepsis war sowohl im Management als auch in Teilen der Belegschaft meiner ersten Arbeitgeber verbreitet und wurde noch größer, wenn Projekte mit diesen Technologien in technischen Schwierigkeiten waren. Performance-, Memory-Probleme waren damals keine Seltenheit, vor allem weil erfahrene Webentwickler noch viel rarer waren als heute und Anfängerfehler in Architekturen schnell gemacht waren. Eine Kuriosität war nun, dass das Management daraufhin zunehmend das Oracle-Datenbankteam die Webprojekte umsetzen ließ, da diese in ihren Client-Server-Projekten erfolgreicher agierten. Da das Team sich am besten in der Oracle-Datenbank-Sprache PL/SQL auskannte, schrieben diese nun im Oracle-Datenbankserver den HTML- und PL/SQL-Code und erschufen aus dem Unterbau einer Softwarearchitektur auch die Fassaden nach außen. Um im Bild zu bleiben, errichteten Tiefbauspezialisten mit ihren Werkzeugen nun die Hochbauten.
Hausinterne Software-Bibliotheken
Auch wenn das Beispiel lange zurückliegt, so setzte sich das von Entwicklern oder implizit durch ihre Fähigkeiten festgelegte Einsetzen von bestimmten Werkzeugen bis heute fort. So sind hausinterne Softwarebibliotheken, die mit einem internen organisatorischen Zwang in jedem neuen Projekt genutzt werden müssen, obwohl es mittlerweile bessere und durch eine viel größere Community gepflegte Open-Source-Alternativen gibt, ein weiteres Merkmal von Dogmahafter Software-Entwicklung.
Sprachenmix
Ein weiteres Beispiel, was in den letzten zehn Jahren den Bibliotheken als der goldene Hammer in Entwicklerkreisen den Rang abgelaufen hat, ist der gemischte Einsatz von diversen Programmiersprachen oder Frameworks in ein und demselben Projekt, weil diese unterschiedlichen Leuten jeweils am besten zusagten. Oder, weil die Personallücke im Team vom Management gerade nur durch den Programmierer geschlossen werden konnte, der leider jedoch nur ein anderes Werkzeug beherrschte und davon so überzeugt war, dass er sich nicht motivieren ließ, das Tool zu erlernen, mit dem der Rest des Teams arbeitete.
So sind Sprachenmixes von Java, Scala, Groovy oder PHP, Perl oder PHP, Ruby immer wieder auch in Projekten mit nur wenigen hundert Entwicklertagen Programmierleistung keine Seltenheit. Auch im Frontend, womit ich hier JavaScript meine, wurden in einem Projekt, in das ich hinzustieß, für ein und denselben Kunden Webfrontends mit Angular, React oder Polymer entwickelt – von natürlich verschiedenen Entwicklern.
Shiny Toys
Die Motivation dahinter liegt manchmal nicht nur im Mangel an passendem Personal oder auch der Spezialisierung von Entwicklern auf bestimmte Werkzeuge sondern auch in der virulenten Schwäche einiger Entwickler, in jeder neuen gehypten Sache die Lösung all ihrer Programmiererprobleme zu sehen. Immer wieder wurden technische Projektleiter überrascht, dass ein Systemarchitekt oder Lead-Developer mit ausgeprägtem Enthusiasmus zu allem Neuem, plötzlich eine Anforderung mit einer anderen, ganz neuen Technologie umgesetzt hat oder dermaßen emotional dafür plädierte, die neue Technologie einsetzen zu dürfen, dass ein Machtwort im Interesse des Unternehmens bzw. der späteren Wartbarkeit der Software durch das gesamte Team gesprochen werden musste.
Dieses sogenannte Shiny Toy, auf das ein Entwickler verfallen ist, wird dabei von der Person zum Goldenen Hammer gemacht, mit der von nun an viel besser als je zuvor sprichwörtlich jede Anforderung an die Wand geschlagen werden kann.
Wartbarkeit gefährdet
Goldene Hämmer, die durch Entwickler ohne Absprache ins Projekt gebracht worden sind, machen Software vor allem nach deren Ausscheiden aus dem Projektteam oder gar dem Unternehmen, zu einer schwer wartbaren Angelegenheit, wenn es sich um ein Werkzeug handelt, was sonst keiner beherrscht. Nicht selten gibt es Stellenausschreibungen, für die ein einzelner Entwickler gesucht wird, der in einem Wartungsprojekt für einen wichtigen Kunden sich darum kümmern soll, als Lonely Coder eine ansonsten im Unternehmen völlig exotische Technologie zu betreuen.
Noch weit aus gravierender beurteile ich jedoch Golden Hammer-Entscheidungen durch das Management, da diese in ihrer negativen Wirkung viel nachhaltiger sein können.
Der Glaube an die Wunderwaffe
Die Wortwahl „Wunderwaffe“ habe ich dem deutschen Wikipedia entnommen, welches den Golden Hammer auf Organisations- und Management-Ebene in dieser martialischen Form übersetzt hat. In der Tat haftet dem Glauben, mit einem bestimmten Werkzeug die Lösung aller komplexen Probleme gefunden zu haben, etwas sagenhaftes, religiöses, mythologisches an, was eher in das Reich der Wunder als in die Realität gehört.
Neben der Fixierung auf ein einzelnes Produkt herrscht manchmal in Managementkreisen zudem ein Glaube an die allgemeine Wirksamkeit von Produkten eines einzelnen Herstellers vor, mit dem man an anderer Stelle gute Erfahrungen gemacht hat.
Im erweiterten Sinn werden auch neue Arbeitsprozess-Ansätze manchmal Religionsgleich propagiert, sei es z.B. im Unternehmen agil oder disruptiv sein zu müssen oder digital zu transformieren, so als sei für alle vorherrschenden Schwierigkeiten nun die Abhilfe schaffende (Wunder-) Waffe gefunden.
Die Anfälligkeit von Dienstleistern
Betrachten möchte ich jedoch Entscheidungen in Dienstleistungsunternehmen, bei dem nicht die Entwickler und in der Firma beschäftigten fachlichen Experten ein Werkzeug einführten bzw. sich dafür aussprachen, sondern eine Management-Ebene.
IT-Dienstleistungsunternehmen geben sich nach außen in der Regel Technologie-offen, sofern sie nicht von vornherein auf Lösungen ganz großer Player wie Microsoft oder SAP spezialisiert sind. In der Praxis müssen sie sich allerdings dann doch auf ein handhabbares Set von Technologien konzentrieren, um die erforderliche Spezialisierung ihrer Mitarbeiter bewältigen zu können.
Aufgrund ihrer (auch wenn eingeschränkten) Offenheit sind sie daher ein Vertriebsziel von kommerziellen Software-Anbietern, die für die Einführung oder Betreuung ihrer Produkte im Markt in der Regel Dienstleistungsunternehmen benötigen. Ansprechpartner beim Dienstleister in diesem Vertriebsprozess sind Entscheider, wie Profit-Center- oder Cost-Center-Verantwortliche oder Geschäftsführer. Weniger adressiert werden jedoch IT-Spezialisten, auch wenn es Software-Anbieter gibt, die in Blogs und Fachmagazinen publizieren, wo eher Spezialisten lesen, um damit hierarchisch gesprochen „von unten“ zu überzeugen.
Der drohende Goldene Hammer im Vertriebsprozess
Genau dieses Vorgehen, Entscheidungsfindung auf Management-Ebene nach Vertriebspartner-Gesprächen, bietet erhebliches (gefährliches) Potenzial für Goldene Hammer-Entscheidungen. Wenn die Management-Ebene an dieser Stelle versäumt ihre eigenen Experten im Unternehmen zu konsultieren, sich möglichst objektiv Pro- und Kontra-Positionen einzuholen, und quasi im Alleingang beschließt, dass ab sofort Projekte nur noch mit der Technologie A statt den schon beherrschten Technologien B, C oder D durchgeführt werden, dann ist der (oftmals falsche) Weg geebnet.
Ich habe dies mehrmals erlebt, übrigens nie auf transparente und klar kommunizierte Weise: Offiziell wurde weiterhin B, C und D als Bestandteil des Portfolios benannt und nun sei eben A hinzugekommen. Sahen aber fachlich-technische Experten beispielsweise bei einem Neukunden die Technologie B als am besten geeignet an, so überstimmte das Management und setzte A durch.
Vertriebsargumente setzen sich durch
Typische Gründe für dieses für Entwickler häufig nicht nachvollziehbare Verhalten sind beispielsweise die durch den Vertrieb des Software-Partners geweckten Erwartungen, die Umsatz- und Gewinnzahlen steigern zu können. Dies vor allem, in dem weniger Personalkosten bei der Projektdurchführung anfallen, da weniger Personentage an Entwickler-Leistungen anfallen würden, geringere Lizenzkosten an den Endkunden weiterzureichen sind und die Vertriebsmacht des Produktanbieters für noch mehr neue Kunden sorgen wird.
Andere Gründe sind Versprechungen, dass man sich langfristig gegenüber den jeweiligen Wettbewerbern durch diese Partnerschaft Vorteile verschaffen wird, wo sowohl der Software-Partner als auch der Dienstleister dann in einer Win-Win-Situation gelangt wären. Kostenlose Schulungen für Mitarbeiter, kostenlose Entwicklerlizenzen, Rabatte bei Lizenzkosten für Kunden, Unterstützungen bei ersten Projekten durch Hersteller-Consultants ergänzen die Liste der objektiven Aspekte.
Wie bei jedem Geschäft zwischen Menschen spielt zu einem wesentlichen Teil das Vertrauen auf zwischenmenschlicher Ebene eine große Rolle, also ein subjektiver Aspekt. Befindet man sich auf einer Wellenlänge, ist man sich sympathisch, fühlt man sich ernst genommen und während des Vertriebsprozesses gut und verlässlich betreut, verblassen die Vertriebskollegen der Partner B, C oder D, um im obigen Vergleich zu bleiben. Diese hat man vielleicht auch schon lange nicht mehr gesehen und wenn, um mitgeteilt zu bekommen, dass sie ihre Preise erhöhen. Somit ist Firma A ein willkommener neuer Partner, mit dem man auf neue Wege gehen möchte. Zumal A geschickt die Nachteile von B, C oder D zu benennen weiß, in dem er sein internes Papier, genannt „Golden Bullets against B, C oder D…„, gut gelernt hat.
Objektive Abwägungen statt Alleingängen
Ich will damit zeigen, dass die Manager an dieser Stelle durchaus menschlich nachvollziehbar und aus ihrer Sicht nicht unstrategisch vorgehen. Der Fehler besteht jedoch darin, die eigenen Experten nur unzureichend, wenn überhaupt, hinzuziehen und die Entwickler-Mitarbeiter rein unter dem Kostenfaktor (Management by Numbers-Anti-Pattern) zu betrachten.
Die eigenen IT-Leute werden in der Regel die kritischsten Betrachter sein, da sie ihre bisher gelernten Produkte und Technologien lieb gewonnen haben und diese gegen alles Neue (vor allem kommerzielles Neue) verteidigen. Hier muss objektiv abgewogen werden, die fachlich-objektive Kritik muss aus der emotionalen Kritik herausgefiltert werden und es muss durch Evaluationen geprüft werden, was Entwickler wirklich für Zeitersparnisse haben. Und es muss abgewogen werden, ob die Mitarbeitermotivation durch das neue Produkt eher steigt oder sinkt.
Auch Endkunden greifen zum Goldenen Hammer
Auf Endkundenseite finden solche Entscheidungsprozesse natürlich ebenso statt. Nicht immer empfiehlt der Dienstleister das neue Software-Produkt eines Drittherstellers frei beim Kunden, sondern dieser hatte mit dem Vertrieb des Software-Herstellers schon vorher Kontakt und sich für dessen Produkt festgelegt, bevor er begonnen hat sich einen Dienstleister für die Projektumsetzung auszusuchen. Die Abläufe sind dann durchaus ähnlich zu den oben beschriebenen.
Hier habe ich übrigens ein paarmal erlebt, dass beim Endkunden ein Angestellter arbeitete, der früher einmal bei einem Dienstleister beschäftigt war, der sich mit dem nun ausgewählten Produkt gut auskannte. Nun sprach er sich deutlich für die Einführung dieses Produktes auch bei seinem neuen Arbeitgeber aus. Das muss nicht zwingend falsch sein, sofern man ohnehin eine solche oder ähnliche IT-Lösung einführen wollte. Aber auch hier bedarf es einer objektiven Abwägung unter Berücksichtigung möglichst vieler Kriterien.
Dadurch das Nicht-IT-Unternehmen weniger IT-Experten beschäftigen als spezialisierte Unternehmen, müssen sie ihre Produktentscheidungen stärker daran ausrichten, ob sie eigenes Personal für die Betreuung haben oder ob sie komplett outsourcen müssen. Die Gefahr, daher das Werkzeug zu nehmen, was man schon kennt oder das neue Werkzeug aus der Palette des schon bekannten Herstellers zu nehmen, auch wenn es nicht das passende für die Anforderungen darstellt, ist hier noch einmal höher als bei Technologie-offenen Dienstleistern.
Gleich mehrere Anti-Pattern
Zum Abschluss noch eine Anekdote aus einem Webprojekt, wo auf Auftraggeber-Seite ein neu eingestellter Systemarchitekt noch nie vorher Berührung mit Content-Management-Systemen hatte und kurz nach seiner Einstellung das laufende Projekt stoppte, da er der Meinung war, dass man solch ein umständliches Werkzeug nicht benötigen würde, wenn man Text- und Bildinhalte auf Webseiten ausspielen möchte. Dies ginge mit einer Datenbank und einem PHP-Framework statt einem Java-basierten CMS alleine viel schneller und kostengünstiger (Golden Hammer & Reinventing the wheel-Anti-Pattern).
Die Programmierung wurde für 3 Monate angehalten, weil in dieser Zeit mehrere Workshops und Präsentationen stattfanden, in der über die Vor- und Nachteile der ein oder anderen Lösung mit dem Auftragnehmer philosophiert und gestritten wurde. Am Ende kam man zurück zum alten Architekturansatz, nicht jedoch ohne einen Gesichtswahrenden, politischen Kompromiss zu finden:
Eine geplante Teil-Applikation, welche mehr funktional, statt Inhalte verwaltend, arbeiten sollte, musste mit PHP und dem gewünschten Framework statt Java und dem CMS umgesetzt werden. Durch einen dann anderen Dienstleister, nämlich dem, bei der jener Architekt vorher gearbeitet hatte.