Pragmatische Richtlinien für die Automatisierung

Es ist quasi ein Meme: „Mit nur wenigen Tagen Skriptschreiben kann man sich viele Minuten an manueller Arbeit sparen.“ Und doch …

Und doch finden sich immer wieder nervige Arbeiten, die Menschen aufschieben, weil sie „hirnlose Arbeit“ sind. Die eigenen Notizen sortieren? Sachen im Wiki dokumentieren? Ich habe eine Kollegin die ihre wichtigen Konsolenbefehle in ihrer Slackhistorie nachschaut (Lieben Gruß an dieser Stelle; ich habe Dich ja gefragt, bevor ich das erzähle … ). Machen wir alle unsere Backups regelmäßig? Vermeiden wir effektiv, uns wieder und wieder durch nervige Webformulare zu klicken? Wir würden doch niemals wieder und wieder dieselben Schritte in unserer Applikation zu Testzwecken ausführen – da gibt es doch heutzutage Tooling für.

Es ist…

Eine psychologische Falle

Wenn wir den Druck als zu groß betrachten, automatisieren wir nicht. Wir versuchen die aktuelle Aufgabe so schnell es geht über die Ziellinie zu schieben. Anstelle von der großen Sparpackung Klopapier kaufen wir die kleine, die den dreifachen Preis pro Rolle hat.

Die Falle daran ist, dass der Druck von außen dann weniger wird, wenn wir unsere Aufgaben schneller und sauberer erledigen. Der Weg aus dieser Falle heraus ist es, kurz Abstand zu nehmen, durchzuatmen, ein pragmatisches Maß an mentaler Resilienz (auch bekannt als Dickköpfigkeit) aufzubauen und dann … eine kleine Timebox Arbeit auf den Casinotisch zu legen und zu schauen, ob man etwas gewinnt.

Ein populärer xkcd-Comic

Randall Munroe – Zeichner und Autor des populären xkcd-Webcomics – hat mal ein wenig für uns gerechnet. Ein kurzer Blick auf die Tabelle verrät: Die Zeitfenster scheinen also doch etwas größer zu sein, als man zunächst annimmt. Stellt sich auch heraus: macht man eine Automatisierungen die dem ganzen Team helfen kann, kann man diese Zahlen sogar mit der Anzahl der Teammitglieder multiplizieren. Ganz zu schweigen davon, dass es eine gute Übung ist, Tests zu schreiben, Skripte zu schreiben und Webautomatisierungen zu konfigurieren (man wird besser und effizienter in Automatisierung wenn man es übt).

Spitzfindige Leser haben aber wahrscheinlich schon den Haken gesehen …

Genau. Fünf Jahre. Ist dieser Task hier wirklich so lange relevant? Wollten wir das alte System nicht sowieso abstellen? Sind wir nicht bald alle in einem neuen Projekt?

Woher wissen wir also was sich denn wirklich lohnt, wenn wir nicht in die Zukunft schauen können?

Kristallkugel gesucht

„Three strikes, then you refactor.“ Martin Fowler hat diese Regel mit seinem Buch Refactoring populär gemacht. Genau wie beim refactorn können wir nur zurückschauen auf die Daten, die wir haben. Im Idealfall fahren wir daher einen agilen Ansatz: Jedes Mal wenn wir dem Problem begegnen, machen wir alles ein kleines Stück besser.

OK. Gut. Ja ähm … Dann mal los. Wir haben jetzt ein fünfzehn-Minuten-Fenster, in dem wir beginnen wollen, eine nervige Aufgabe effizienter zu bewältigen. Unser Editor ist offen, unser Cursor blinkt freundlich und wartet darauf, dass wir mit dem Tippen anfangen.

Und nun?

Notizen sind der erste Schritt

Am Anfang muss man das Problem erstmal verstehen. Manchmal gibt es schon eine Dokumentation, die vielleicht unvollständig oder veraltet ist. Der erste Schritt ist hier, ein paar kleine Korrekturen zu machen.

„Ja aber Eric, wolltest Du wolltest Du hier nicht über Automatisierung sprechen? Das Einzige was ich furchtbarer finde als undurchsichtige Bash-Skripte sind staubige Wikiseiten!“ Das hier ist schon Automatisierung. Du automatisierst Dich selbst.

In dem Moment, in dem die Aufgabe so gut beschrieben ist, dass auch eine projektfremde Person sie ausführen kann, indem sie den Anweisungen folgt, ist es quasi nur noch ein Skript. Du musst es nur noch übersetzen. Alle nervigen Edge Cases sind gesammelt. Die Fehlermeldungen, die kommen können, kennst Du. Der Rest ist nur noch ein wenige Getippsel.

Jede Automatisierung kann skaliert werden

Jede Notiz kann in ein Wiki (oder einen Blog, …). Jedes Skript kann in ein Repo. Jedes Skript in einem Repo kann in ein Buildtool integriert werden. Alles was schon im Buildtool drin ist, kann auch gleich Jenkins ausführen.

Viele Open-Source-Projekte haben anekdotisch damit angefangen, dass Programmierende einen „itch“ hatten, ein juckendes Gefühl, etwas, was gefehlt hat, was sie mit seinem Tool herbeischaffen wollten. Das fehlende Jenkins-Plugin für den eigenen Technologiestack, das fehlende Stück Gluecode, kann also durchaus ein paar Sterne auf GitHub bringen.

Das bringt mich auch zu meinem nächsten Punkt.

Gibt es da vielleicht was von Ratiopharm?

So sehr wir auch glauben wollen, dass unsere Probleme einzigartig sind, haben ein paar der Milliarden Menschen auf diesem Planeten mit Sicherheit schon ähnliche Probleme gelöst. Der mentale Widerstand dagegen ist das bekannte Not inventented here-Syndrom. In Zeiten von ChatGPT braucht es dafür auch kein starkes Google-Fu mehr; mit ausreichenden Notizen kann man leicht einen AI-Prompt formulieren und sich eine Liste von möglichen Werkzeugen abholen.

Weniger mentale Reibung

Erfahrung ist die Erinnerung an Schmerzen. Ein Skript auszuführen, das etwas was vorher schmerzhaft war voll automatisch und in wenigen Sekunden erledigt, fühlt sich besser an als ein warmes Bad. Rein psychologisch gewinnen wir schon so die Kontrolle über unsere Umgebung wieder. Wir sind Software-Entwickler. Wir lösen neue Probleme. Jede wiederkehrende, nervige Aufgabe steht auf dem Prüfstand, wegautomatisiert zu werden.