Der Toolkurator

Der Toolkurator ist eine tickenden Zeitbombe in der Modernen IT - insbesonder im Webfeld ist in fast jeder Firma anzutreffen. Warum diese meist harmlos anmutende Person geradezu toxisch für jedes Unternehmen ist, möchte ich im Folgenden lang und breit erläutern.

TLDR; Gerade heraus: Der Toolkurator ist ein verantwortungsloser Idiot. Dessen ist er sich leider nicht bewusst.

Es gibt ihn in zwei Ausprägungen. Bei einer besteht noch Hoffnung, beim Zweiten ist Hopfen und Malz verloren.

Der Youngster:

Die erste Ausprägung ist ein Anfänger, den man nicht mal als Junior Irgendwas bezeichnen kann. Er ist sich seiner Defizite sehr wohl bewusst und ist motiviert sie möglichst schnell aufzuholen.
Anstatt sich aber mit dem was er eigentlich leisten soll zu beschäftigen, sucht er nach dem schnellen Erfolg.
Er versucht immer brandaktuell zu sein und ist deshalb bestens über den neuesten Buzz/Hype informiert. Da sein Können nicht ausreicht, um Dinge erfolgreich selbst zu schaffen, ist er ständig auf der Suche nach irgendwelchen Tools, die schnelle Lösungen versprechen (und mit schnell ist hier sicher nicht effizient gemeint).
Wenn das Programm nicht so verschrien wäre, würde er Dreamweaver nutzen, um sich bloß nicht mit dem beschäftigen zu müssen, was er eigentlich tun sollte.
Brandaktuell zu sein hat bei ihm Methode. Keines seiner Werkzeuge ist älter als zwei Jahre. Garantiert nicht genug Zeit, dass irgendjemand damit nennenswerte Expertise hätte aufbauen können. So liegt die Messlatte um zur Avantgarde zu gehören verheißungsvoll niedrig.

Das Alteisen:

Bei diesem Subjekt handelt es sich nicht wirklich um einen Anfänger. Er hätte locker genügend Zeit gehabt, es in irgend einem Feld zum Senior Irgendwas zu bringen.
Es mangelt ihm aber an Selbstvertrauen bzw. Vertrauen in die eigene Arbeit.
Da er bei Problemen schnell frustriert ist und aufgibt, hat er eben in seiner langen Arbeitszeit keine nennenswerten Kompetenzen erworben und hängt nun gleich alten Kollegen auffällig hinterher.
Das heißt, es würde auffallen, wenn er es zuließe und irgendetwas abliefern würde, was sich mit der Arbeit seiner Kollegen vergleichen ließe. Das tut er aber bewusst nicht.
Bzw. er ist über die Zeit ein Meister des Vortäuschens geworden. Er liefert nämlich durchaus Resultate, die von Projektmanagern und anderen Entscheidern wahrgenommen werden - und diese Resultate sind auf den ersten Blick überzeugend, weil sie auf seinem System und einem frühen Live Projekt funktionieren. Gegen Erfolg ist schwer zu argumentieren.

Gerade deshalb ist es so wichtig es dennoch zu tun, solange der Toolkurator sein zerstörerisches Potential noch nicht vollends entfaltet hat.

In ganz seltenen Fällen sitzt der Toolkurator selbst in der Geschäftsleitung. Dort entfaltet er sein seltsames Treiben aber nicht, um die eigenen Unzulänglichkeiten zu kompensieren. Er verwendet die Tools auch nichts selbst, was es ungemein schwieriger macht, mit ihm darüber zu reden, weil er sie gar nicht kennt.
Das hat er gar nicht nötig, denn er ist nicht in der Situation, dass er was er plant auch umsetzen müsste. Er ist getrieben von den beiden Schlagwörtern einfach und schnell.
Beide Begriffe sind im Management synonym für Profit. Nicht umsonst sind es wohl die häufigsten Buzzwords auf den Homepages der Toolanbieter.
Mit dem Einsatz aktuellster Tools kann man sich im Gespräch halten, sich als jung und dynamisch verkaufen.
Zockermentalität trifft es meiner Meinung nach besser.

Der Toolkurator hat in de heutigen IT Welt einen guten Stand. Der Zeitdruck ist enorm und die Budgets geben kaum Raum für ordentliche Analysen und maßgeschneiderte Software.
Nicht selten ist der Toolkurator der Erste, der eine funktionierende Lösung präsentieren kann. Es gilt der Grundsatz:

Wer liefert, hat recht.
Doch wie macht er das?

Er ist ein Meister der Suchmaschine. Obendrein kann ihm auf dem Feld der Tools keiner was. Er macht fast nichts anderes. Während der Rest der Firma in kleinen fiesen Details hängt und versucht Probleme älterer Software zu lösen, oder auch detaillierte Kundenwünsche zu implementieren, ist er pausenlos auf der Suche nach fertigen Lösungen. Mit seinem Umfassenden Tool Know-How kann er daher in beeindruckender Zeit die richtige Kombination von Tools ermitteln. Dann kommen noch weitere Tools, um die Tools zu kombinieren, Tools um den Zusammenbau zu Automatisieren und fertig ist der Prototyp, der mit den entsprechenden Tools sofort auf Production deployed werden kann. Management und Firmenleitung sind begeistert.

READY.
LOAD MAGIC,8,1

SEARCHING FOR MAGIC
LOADING
READY.
RUN

So schafft er es, durch seinen scheinbaren Erfolg, die Kompetenz, die er nicht hat, als überflüssig da stehen zu lassen.
Ein Relikt aus den Anfängen der IT, wo es noch sagenumwobene Experten gab, die sich ihr Know-How durch verlustreiche Fehlschläge und gerade auch deren Überwindung erarbeitet hatten und für die Unternehmen mal ein Vielfaches seines Lohns auf den Tisch legen mussten, damit sie für sie arbeiteten.
Weniger Gehalt, mehr Erfolg? Für Toolkurator und Unternehmen ein Win-Win.
Bonus: Toolkurator kann wirklich Jeder werden, dessen Arbeit im Unternehmen irrelevant genug ist, um ihm genug Zeit zu verschaffen, sich ausgiebig mit Blogs, Tool-Fachzeitschriften und eben mit den Tools selbst zu beschäftigen.

Viele werden an dieser Stelle denken:

Der Erfolg gibt ihm Recht!

Wenn dem auf lange Sicht so wäre, würde ich mir nicht die Mühe machen, diese Zeilen zu schreiben.
Neid kann die Ursache dafür nicht sein, denn wie ich erwähnte ist es sehr einfach, Toolkurator zu werden.
Demnach hätte ich sicher selbst genug Zeit gehabt, gepaart mit meinem altbackenen Know-How zum Master-Toolkurator zu werden.

Was ist es also, was diese Person so gefährlich für ihre Kollegen und das Unternehmen macht?

Der Toolkurator hat keine Ahnung!

Wie jetzt? Gerade wurde doch erklärt, dass er dank Tools trotzdem zum Erfolg kommt?

Ein Beispiel: Der Toolkurator hat keine Ahnung was “die Cloud” ist.

Das was wir heute als “die Cloud” Kennen, wurde entwickelt, um die Probleme mit der Infrastruktur großer Datencenter zu lösen. Dazu zählen:

1. Server Monokulturen, die schlecht ausgelastet werden können, weil ihre Größe für keinen Anwendungsfall so wirklich passt. Zudem dauerte bei Engpässen der Einkauf zusätzlicher Server viel zu lange.
2. Netzwerke die per Hand umgesteckt werden mussten, was bei Massen von Kabeln zeitaufwändig und fehleranfällig war.
3. Unzureichende Kapselung der Dienste, die um die Effizienz des Datacenters zu steigern, auf die gleichen Server installiert wurden, was zu schwer zu testenden unvorhersehbaren Seiteneffekten führen kann.

All diese Probleme haben die Cloud Anbieter mit eigenen proprietären Lösungen längst in den Griff bekommen. Sie bieten:

1. Verschiedene Instanz Klassen, so dass es für jeden Dienst die passende Instanz Klasse gibt und man beliebig viele gleiche Instanzen dieses Dienstes starten kann. Wenn die Klasse nicht mehr passt, nimmt man halt eine andere.
2. Komplett virtualisierte Netzwerke, die es einem erlauben, virtuelle Firewalls und Switches schnell zu konfigurieren und Dienste ebenso schnell nach belieben zu verbinden und zu Isolieren.
3. Durch Virtualisierung der Instanzen, oder auch Vorhalten realer Systeme in verschiedenen Größen, sind die Dienste jederzeit voneinander gekapselt. Seiteneffekte zwischen Diensten, die durch die gemeinsame Nutzung von Hardware entstehen, treten so nicht mehr auf.
   Woran man jetzt merkt, dass der Toolkurator keine Ahnung von Cloud Infrastruktur hat, ist der simple Fakt, dass er sie nicht nutzt. Stattdessen benutzt er Container.
   An Containern ist so erst mal nichts falsch, aber er benutzt sie falsch.

Container Infrastruktur wurde mit exakt den gleichen Zielen entwickelt, die auch den Anstoß für die Cloud gaben. Lösung 2. ist quasi äquivalent, die anderen beiden Punkte kurz umrissen:
Container brauchen keine Instanz Klassen. Stattdessen versucht man damit mehrere Dienste auf einem geteilten Betriebssystemkern laufen zu lassen, wie es auch schon vor Cloud und Containern der Fall war, aber diese durch zusätzliche Maßnahmen besser zu Isolieren, so dass weniger Seiteneffekte auftreten und man viele Dienste auf einem Server stapeln kann, bis dieser so Ausgelastet ist, das er kosteneffizient läuft.

Container lösen hier also keine neuen Probleme, sondern sind ebenfalls für große Datacenter mit komplexen Netzwerken und Server Monokultur ausgelegt.

Auch die Auslastung kann nicht als Argument genommen werden.
In der Cloud hat die kleinste Instanz ungefähr die Leistung eines Raspberry-PI und viel kleiner sollte man auch für Microservices nicht gehen, um ein bisschen Luft für Unvorhergesehenes und Bursts zu haben. Nicht umsonst bieten die kleinsten Instanzen bei AWS die Fähigkeit bei Bursts auf Basis von akkumulierenden Creditpoints kurzzeitig mehr Leistung zu bieten.

Welches Problem löst also der Toolkurator mit Containern in der Cloud?

Der Toolkurator möchte in oberster Priorität das altbekannte “auf meinem System funktioniert das” zu einem gültigen Argument machen. Cloud Systeme sind auf seinem System nicht ausführbar und müssen in der Cloud entwickelt werden, unter der Verwendung der anbieterspezifischen API.
Da der Toolkurator sich im Unternehmen hochbuzzt, hat er in seiner Entwicklungsphase keinen Zugriff darauf und kann nicht mit automatisierten Cloud Systemen glänzen.
Er braucht ein Demo System, welches nahtlos von seiner Entwicklermaschine auf Live Systeme übertragbar ist. Er argumentiert gerne damit, dass sein System anbieterunabhängig ist und theoretisch sogar über mehrere Anbieter hinweg funktionieren würde.
Das ist zwar richtig, aber operativ aufgrund der Latenzen kompletter Bullshit, weshalb höchstens die Portabilität zwischen Anbietern ein Argument wäre. Wer die Qualitäten der Anbieter kennt, wird nicht mitten im Projekt den Anbieter wechseln wollen.
Selbst wenn, wäre es auch mit Containern ein ziemlich aufwändiger Prozess.

Was ist nun so schlimm an Containern in der Cloud?

Cloud und Container sind zwei ähnliche Lösungen desselben Problems. Da es keinen Sinn macht, nur einen Service pro Micro Instanz in Containern aus zu rollen, baut der Toolkurator erst mal alle Vorteile der Cloud zurück.
Er nutzt nichts davon. Stattdessen baut er mit Cloud Infrastruktur ein altbekanntes Datencenter auf, in dem er dann mit Containern arbeiten kann. Das ist nicht nur operativ offensichtlich Unfug, sondern auch ökonomisch betrachtet.
Mit steigender Instanz Größe gibt es selten Preisnachlässe, stattdessen steigen die Preise schneller, als die Leistung der Instanzen. In einem Datencenter, das Cloud Virtualisierung anbietet, ein Datencenter für Container einzurichten ist also teurer, als die Cloud Virtualisierung mit ihren Lösungen für die gleichen Probleme direkt zu nutzen.
Außerdem ist es nicht sinnvoll einen weiteren Abstraktionslayer einzuziehen, der keinen weiteren Nutzen bietet.
Wer ein Container Image bauen kann, kann auch ein Instanz Image für die Cloud bauen, bzw. seine Software direkt auf ein passendes Basisimage deployen.
Es ist kein Container erforderlich.

Der Ansatz ist genauso widersinnig, als wenn man Container dazu nutzen würde, um darin VMs zusammen zu bauen und mit diesen Containern VMs auszuliefern.
Das hat zum Glück noch niemand medienwirksam versucht, weshalb wir es noch unbiased als widersinnig wahrnehmen können.

Schneller skalieren als in der Cloud kann man auch mit Containern nicht, denn das System würde anfangen zu oszillieren, wenn man die gemessene Last nicht einigermaßen mittelt und statt in Minuten in Sekunden reagiert, was mit Containern prinzipiell möglich wäre. Also ergibt sich auch hier kein operativer Vorteil.
Die eigene Cloud Infrastruktur hat bei den meisten Anbietern eine hervorragende API und lässt sich bestens Automatisieren, wofür es auch ernstzunehmende Tools gibt. Auch hier bietet der Container in der VM keine Vorteile.

Am Rande erwähnt: Googles Container Engine ist eine gut funktionierende Implementation des Containers Ansatzes, ohne einen zusätzlichen Layer an Cloud Techniken, die man mit Containern doppeln würde. Auf diese Art Container zu deployen macht durchaus Sinn.
Das tut der Toolkurator aber nicht.

Wenn der Toolkurator also Unsinn entwirft, wieso lässt man ihn gewähren?

Das Problem liegt bei dem, was in Management Etagen heutzutage als Erfolg definiert wird.
Denn auch dort liegt die Messlatte so niedrig wie nie zuvor. Erfolg ist dann, wenn das Setup sich auf der Entwicklungsumgebung des Toolkurators so verhält, wie vom Kunden gewünscht.
Diese Umgebung ist, ja dank Tools eins zu eins übertragbar auf das Produktivsystem, oder nicht? Oder nicht?

Nein!

All die Tools und Abstraktionen mit denen der Toolkurator arbeitet, werden niemals die gleichen Bedingungen herstellen können, wie sie auf dem skalierenden Produktivsystem vorliegen.
Insbesondere dann nicht, wenn das System unter eine Last gerät, die sich nicht mit dem schicken extra slim sub Irgendwas-Dings des Toolkurators verarbeiten lässt. Ganz zu schweigen von dem noch größeren Problem, eine realistische Last überhaupt zu erzeugen (dazu komme ich noch).

Kurz gesagt: Der Toolkurator testet nicht richtig!

Wie denn auch. Er wüsste ja nicht mal, was er testen soll. Wenn er das wüsste, wüsste er immer noch nicht wie. Er kennt die Komponenten, des von ihm zusammengetoolten Systems nicht ausreichend, um sie testen zu können.
Er verlässt sich voll und ganz darauf, dass seine Community von Toolkuratoren das schon gemacht haben wird.
Dabei bedenkt er nicht, dass seine Zusammenstellung von Tools garantiert noch nie in Kombination getestet wurde, weil es das Produkt sonst schon gäbe und er gerade nicht daran sitzen würde.

Wenn er eine Datenbank deployed, weiß er nicht, was in ihrer Konfiguration steht. Im Optimalfall Defaultwerte - Worst Case: Irgend ein undokumentierter Hack, den ein anderer Toolkurator aus einem Blog abgeschrieben hat - ohne ihn zu verstehen - um irgend ein ganz anderes Problem zu lösen.
Er weiß auch nicht, dass seine als verteilt, horizontal skalierend geplante Datenbank niemals effizient skalieren wird, weil das Backend - von dem er auch nichts weiß - nach jedem Write einen Read auf dieselben Daten schickt, um das Frontend zu aktualisieren und zu testen, ob die Daten wirklich geschrieben wurden.

Erklärung: Deshalb müssen alle DB Nodes warten, bis die Daten auf allen relevanten Nodes geschrieben wurde (100% Konsistenz Anforderung).
Richtig wäre es, das Frontend mit den gerade geschriebenen Daten zu aktualisieren und auf den Abschluss des Writes asynchron zu warten, um ggf. auf Fehler zu reagieren.
Eine Datenbank die nicht mitbekommt, dass ihr Write fehlgeschlagen ist, ist keine Datenbank.

Warum macht man das nicht gleich so?

Weil man dann nicht dieselbe Funktion verwenden könnte, die man zum normalen Abfragen von Daten benutzt und die Fehlerbehandlung einiges schwerer wird, wenn das System schon weitergelaufen ist und der Fehler nachträglich behoben werden muss.

Ein System das blockiert, bis der Read nach dem Write durch ist, ist halt viel einfacher zu schreiben. Es skaliert bloß schlechter als eine einzige Node, die keine Daten synchronisieren muss.
Toolkuratoren, die Tools für Toolkuratoren schreiben.

Deployed der Toolkurator einen Webserver - erraten: Defaultwerte. Er könnte nicht sagen wieviele Verbindungen das System gleichzeitig halten kann, wann er aufgrund von Ressourcenmangel skalieren muss, usw.
Und das ist selbstverständlich nur ein Beispiel.
Einen Webserver für ein spezifisches Projekt optimal zu konfigurieren ist eine Kunst - die der Toolkurator nicht beherrscht.

Aber wozu denn einen Webserver? Heutzutage bringt doch jede dem Toolkurator bekannte Programmiersprache entweder selbst einen Webserver mit, oder hat ein Projekt in der Community, dass eben dies leistet und so richtig Buzz macht.

Lassen wir doch einfach das große, böse Internet direkt auf dieses Projekt einhämmern und schlimmstenfalls mit einem fiesen kleinen Request abstürzen, den man im Webserver schon hätte ausfiltern können. Immer und immer wieder.

Noch nicht genug?

Der Toolkurator richtet dir in Windeseile eine CI Pipeline ein, die jeden kleinen Commit sofort auf Live schleudert. Menschliche QA? Im Moment des Livegangs abgeschafft (Ooops!).
Ein paar Tage später fällt dann auf, dass wirklich jeder Mist auf Live landet, egal ob er funktioniert, oder nicht. Staging und Beta Systeme braucht man dank CI nicht mehr, wer sollte die auch testen, wenn jeder Commit potentiell sofort live gehen soll.
Also Tool automatisiertes Testen. Schnell ein neues Tool, mit dem schnell und einfach die ganze Firma zu Testern umfunktioniert werden kann.

Wie das geht?

Ganz schnell und einfach: Es wird nicht die Software getestet, sondern eine ehemals menschliche Frontend QA mit einem Tool automatisiert. Im Wesentlichen also eine Klickstrecke automatisiert, die für jede auf die Schnelle erdenkliche Eingabe, die Ausgabe überprüft.

Wenn man so eine 100% Testabdeckung schafft, ist doch alles wieder gut?

Nein, ist es nicht. Damit hat man nur 100% aller über das Frontend möglichen (Fehl-) Eingaben abgetestet.
Das Frontend sendet aber keine UI Klickstrecke sondern schnöde HTTP Requests.
Diese lassen sich beliebig umformulieren und so eine Vielzahl von Angriffen zu, die die Abdeckung der Frontend Klickstrecke in den Promillebereich zurückfallen lassen.

Das müsste aber auch bei “normalen” Projekten desaströs sein, oder?

Nur zum Teil. Wie schon erwähnt würde man normalerweise schon im Webserver Requests filtern, die keine sinnvolle Funktion im Backend ansteuern. Dazu kommt, dass bei altbacken und langsam entwickelten Projekten meist jede Komponente von irgendeinem Mitarbeiter des Unternehmens mal angefasst, konfiguriert und vielleicht sogar ein bisschen getestet wurde.
Daher sind ein guter Teil der Schwächen bekannt und wenn es nicht vorher schon gemacht wurde, wäre jetzt genügend Know-How da, Backend Tests zu schreiben und die Interaktion aller Komponenten zu Prüfen.
So könnte man sogar eine halbwegs funktionierende CI Pipeline zusammen bauen. Nachträglich und unter Zeitdruck macht man dabei vermutlich eher mehr kaputt, als dass korrigiert wird.

Es fehlt aber noch eine dritte Klasse von Tests: Die Lasttests.
Aus Frontend Tests lassen sich unter keinen Bedingungen Lasttests bauen.

Die Aufgaben sind Disjunkt, keine Synergie. Nichts. Nada.
Vergiss einfach alles, was dir irgendwelche Startups oder aufmerksamkeitshaschende Blogs erzählen wollen.

Wieso?

Generiere mal einfach mit automatisierten Browserklicks die Last, die mindestens Tausend (vielleicht sogar eine Million?) Browser erzeugen können! Auf welchem System? Welcher Server (Cluster?) schafft mehr als zehn bis zwanzig, völlig unabhängige Full Blown Browser gleichzeitig? Wie modelliert man aus diesen reinen Funktionstests realistische Usage Patterns? Keine Ahnung? Ich auch nicht!
Der beste Lasttests kommt meiner Erfahrung nach aus einem Mitschnitt des Live Verkehrs eines frühen Prototypen. Aber diesen Mitschnitt bekommt man nicht so einfach aus einem getoolten System heraus. Es gibt keinen vernünftigen Ort, wo man mal eben einen Wireshark, oder *dump dazwischen hängen könnte.
Selbst wenn man einen hätte, könnte man nur Replays fahren. Viele Systeme sind aber absolut nicht Stateless (nicht zu verwechseln mit einer eventuellen stateless API), so dass man z.B. die selbe Rechnung nicht zweimal buchen kann und dasselbe Verhalten erreicht.
Jeder Replay ergibt nur eine Fehlermeldung, die vermutlich viel weniger Arbeit auf dem System erzeugt und schon wieder kein realistisches Lastverhalten ergibt.

An dieser Stelle hat uns der Toolkurator ein Minenfeld aus lauter Blackboxen hinterlassen.

Komponenten die der Toolkurator ohne Review zusammengeschustert hat, die man eigentlich alle einzeln und in Kombination hätte testen müssen.
Man hätte auch automatisierbare Testcases dafür schreiben können, oder zumindest downloaden und einbauen können.
Die Zeit die bis zum Livegang gespart wurde, weil der Toolkurator sich nicht mit den einzelnen Komponenten seines epischen Spaghettimonster aus PHP, Ruby, Python, NodeJS und völlig unbekannten Binaries beschäftigen musste, fehlt jetzt Live vor den zurecht unzufriedenen Kunden.

Um es in Zahlen zu nennen es wurden in etwa fünf Monate reguläre Entwicklungsdauer in vier bis sechs Wochen eingestampft. Das fehlende Know-How muss jetzt während der Havarie erworben werden. Unter enormem Druck.
Dadurch sinkt die Konzentration und man arbeitet im schlimmsten Fall langsamer und fehleranfälliger, als in der regulären Entwicklungsphase. Diese Arbeit macht aber nicht der Toolkurator. Dazu fehlt ihm die Qualifikation.

Wenn die Firma das überlebt, wird höchstwahrscheinlich nicht mal der Toolkurator den Kopf dafür hinhalten müssen.
Er kann sich auf eine breite Community von

Bei XY hat das aber auch funktioniert!

berufen, die allesamt coole Boilerplate Websites haben, auf den wieder nur einfach und schnell steht, aber niemand ins Detail geht, wie er denn nun eigentlich ein konkretes Problem gelöst hat, was die konkreten Anwendungsbereiche für ihre Tools sind und am Wichtigsten: Wofür man sie besser nicht benutzen sollte.
Es arbeiten heutzutage sowieso alle so und bestimmt war nur die schlechte Infrastruktur schuld, die der Tooklurator natürlich nicht mitgestaltet hat.

Davon hört man heutzutage noch erstaunlich wenig und man könnte mir jetzt zurecht Schwarzmalerei unterstellen.

Nur ist es leider so, dass es in Deutschland noch keine ausgeprägte “Why we failed:” Kultur gibt.
Die wenigen Vorträge die es gibt, beschäftigen sich größtenteils mit Missmanagement und Startups, deren Businessidee schon völliger Schwachsinn war.
Wer Erfolg hatte, zieht die Augen auf sich und bestimmt die Richtung des Hype - dort wo diese Herangehensweise scheitert, scheitert jeder leise für sich alleine.

Natürlich ist das gewähren lassen eines Toolkurators auch extremes Missmanagement, aber in den Führungsetagen träumt jeder davon ein klein bisschen wie Google zu sein.
Die Arbeiten ja auch mit unglaublich vielen Tools.

Nur das Google seine Tools selbst schreibt, sicherlich auch massiv testet und Special-Ops-Tool-Teams in Hotstandby hat, die für Probleme Zeit haben, während die regulären Truppen normal weiter arbeiten.

Ihr habt aber nur ein oder zwei Toolkuratoren, deren größte Leistung es wäre, ein Tool zu schreiben, welches andere Tools automatisiert. Ungetestet. Was dann im Extremfall von anderen Toolkuratoren massenhaft geladen wird, weil sie darauf vertrauen, dass die Toolkuratorencommunity das schon getestet haben wird.

Zur Klarstellung: Ich spreche mich ausdrücklich nicht gegen Software Reuse aus. Das ist einer der Grundpfeiler der OpenSource Community.
C ist Software Ruse von Assembler.
Go ist Software Reuse von C.
Jedes Programm dass eine Library linkt ist Software Reuse.
Jede Distribution, stellt nur bereits existente Software zusammen.

Doch eben da liegt der Unterschied zum Treiben der Toolkuratoren:
Eine Distribution bringt jede Library pro Revision nur einmal mit und teste gnadenlos alle gelinkten Programme, ob sie damit funktionieren. So kann man innerhalb einer Stable Version gefahrlos weiterarbeiten, ohne Angst zu haben, dass sich jederzeit eine Abhängigkeit ändern könnte.
Der Toolkurator erschafft ein Knäul aus automatisch von extern geladener Software, dass nur im Zeitlichen Umfeld des letzten manuell überwachten Build stabil sein kann, selbst wenn jede Komponente in ihrem Container stabil wäre. Diese Software ist aufgrund einmalig angepasster Abhängigkeiten unwartbar.
Die Release Cycles (wenn man es denn so nennen will) der Tools sind viel zu kurz und was einmal funktionierte, kann mit der nächsten Version der Tools schon wieder unmöglich sein.
So schaffen die Toolkuratoren genau zu diesem Augenblick einmal reproduzierbare Builds, bei denen es keine Long Term Stability Garantien geben kann.
Schreiten die Versionen voran, kann es schnell sein, dass sich ein vergleichbare Projekt mit den bestehenden Tools, ohne massive Handarbeit, überhaupt nicht mehr zusammen bauen lässt.
_Der Zeitpunkt an dem die eigentlich Arbeit gemacht werden muss, rutscht also nur hinter den vermeintlichen Livegang und muss jetzt ohne Budget auf kosten anstehender Projekte eingeschoben werden.
_Oder man lässt das Projekt sterben - es ist immerhin schon über ein Jahr alt und der Kunde lässt sich nicht für ein neues Budget gewinnen, das deutlich über dem Ersten liegen wird.

Ist die CI Pipeline eines unter “läuft ja” verbuchten Projekts einmal defekt, wird der nächste erfolgreiche Build desselben Projekts einiges schwerer sein, als nur eine Migration in eine neuere Version derselben Distribution, denn jetzt greifen keine Defaults mehr und der Buildprozess muss angepasst werden. Es muss eine zum ersten Livegang kompatible Konfiguration geschaffen werden. Die erste Konfiguration ist aber dank Tools weitestgehend unbekannt. Also kann man trotz CI entweder keine Sicherheitsrelevanten Updates vornehmen, oder man hat mit der CI eine Dauerbaustelle, die in kleinen Betrieben mehr Zeit verschlingt, als wenn man die Software altmodisch in getesteten Releases ausliefert.

Hat man Massen an Mitarbeitern, die alle hinter der selben CI arbeiten rechnet es sich, ein Team ausschließlich für die CI ab zu stellen.
Ich habe nie erlebt, dass dafür in kleinen Unternehmen ein regelmäßiges Zeitkontingent vorgehalten wurde. Also bleibt dieser Job nicht selten an einer einzigen Person in Teilzeit hängen, oder die CI bleibt bis zum End of Live des Projekts wie sie ist, weil schon längst wieder neue Projekte anstehen, die Tools und CI brauchen.

Daher mein gut gemeinter Rat:
Winkt ein Job in einer Firma mit Toolkurator - nimm ihn nicht an.
Hat sich in deiner Firma ein Toolkurator entwickelt - kündige.

Ich sage nicht, dass ich eine Patentlösung habe, wie man mit sauber entwickelter Software heute noch konkurrenzfähig bleiben kann, aber: Wenn diese Art auf “wird schon gutgehen” zu zocken, wirklich die neue Art der Softwareentwicklung sein soll, wird das wohl nur eine reihenweise Insolvenz der “Bad Player” korrigieren.

Noch was aktuelles zum Thema auf Heise:
Martin Thompson: _”Wir müssen uns auf Einfachheit und Eleganz zurückbesinnen”
_

Und mit einfach ist hier sicherlich nicht “du musst dazu nichts können“ gemeint.