#62 Technologien konsolidieren, oder wie Startups sammeln?

Was ist der richtige Ansatz? Ein Stack für die ganze Firma oder jedes Team darf die Technologie wählen, wie es möchte?

Die Wahl der richtigen Programmiersprache, der richtigen Datenbank, der richtigen Cloud-Umgebung. Gibt es etwas, worüber sich Software-Engineers mehr streiten können? Doch genau diese Fragen stehen i.d.R. beim Start eines Projektes an. Zumindest, wenn das Team die freie Wahl hat. Dies ist das eine Extrem. Im anderen Extrem wird die Sprache und der Stack von der Firma vorgegeben und im Rahmen wird auch operiert. Was ist nun besser? Was sind die Vorteile von "Alles ist möglich"-Ansatz? Und warum sollte man diese nicht wählen? Und welche Gründe gibt es für den "Ein-Stack"-Ansatz? Und was passiert, wenn die Firma von einem Extrem ins andere wechseln möchte? Wie geht man bei einer möglichen Technologie-Konsolidierung vor? Was passiert mit der Innovationsfreudigkeit? Welchen Effekt hat dies auf die Mitarbeiterinnen? All das und noch viel mehr gibt es in dieser Episode.

Bonus: Wird in Innsbruch alles immer neu entwickelt und ob das Spagetti Eis nur in NRW bekannt ist.

Das schnelle Feedback zur Episode:

👍 (top) 👎 (geht so)

Sprungmarken

(00:00:00) Intro

(00:01:03) Lieblingsprogrammiersprache und die Migration auf JavaScript

(00:03:22) Zwei Extreme: Einheitlicher Stack oder Jeder darf wählen was man möchte

(00:06:18) Vorteile vom "Alles ist möglich"-Ansatz

(00:12:46) Nachteile vom "Alles ist möglich"-Ansatz

(00:24:39) Vorteile vom einheitlichen Stack-Ansatz

(00:29:58) Nachteile vom einheitlichen Stack-Ansatz und wird die Innovationsfreudigkeit geblockt und Legacy-Apps fördert?

(00:34:58) Konflikte und Emotionen bei Konsolidierungen

(00:40:07) Wie kann eine Konsolidierung durchgeführt werden?

(00:55:42) Effekt auf die Mitarbeiter bei einer Konsolidierung

(01:00:04) Wie ist der Stand bei euch in der Firma? Steht eine Konsolidierung bevor?

(01:01:30) Welcher Ansatz ist denn nun der beste?

(01:07:07) Zusammenfassung

Hosts

Wolfgang Gassler (https://mastodon.social/@woolf)
Andy Grunwald (https://twitter.com/andygrunwald)

Feedback (gerne auch als Voice Message)

EngKiosk Community: https://engineeringkiosk.dev/join-discord
Email: stehtisch@engineeringkiosk.dev
Mastodon: https://podcasts.social/@engkiosk
Twitter: https://twitter.com/EngKiosk
WhatsApp +49 15678 136776

Transkript

Das Transkript wurde automatisiert per Speech-to-Text erstellt und kann daher Fehler enthalten.

Wolfi Gassler (00:00:04 - 00:01:05)

Was machst du, wenn deine Lieblingsprogrammiersprache oder dein Lieblingsframework in deiner Firma nicht mehr gewünscht wird? Einfach einmal so wegkonsolidiert. Und mit dieser Frage heißen wir dich herzlich willkommen bei einer neuen Folge des Engineering Kiosks. Start-up haben ja oft den Autonomieansatz, beliebige Technologien, Hauptsache es geht schnell, effizient und löst ein Problem. Die Big Player hingegen sind meist wesentlich unflexibler. Aber was ist denn der bessere Ansatz im Sinne von MitarbeiterInnen-Motivation, Produktivität, Entwicklungsspeed, Innovationsfreundlichkeit, Wartbarkeit, Recruiting und Onboarding? Und was passiert, wenn man langsam als Startup wächst und irgendwann fünf Clouds gleichzeitig nutzt? Macht das überhaupt noch Sinn? Muss konsolidiert werden? Und wenn ja, wie konsolidiert man, ohne dass dabei alle aus Frust kündigen? Viele Fragen, die wir versuchen in dieser Episode zu beantworten. Und los geht's! Andi, was ist deine Lieblingssprache?

Andy Grunwald (00:01:05 - 00:01:08)

Ich würde gerne Französisch können, aber ich bin echt nicht talentiert.

Wolfi Gassler (00:01:08 - 00:01:11)

Richtige Programmiersprache meine ich, also echte Sprache.

Andy Grunwald (00:01:11 - 00:01:42)

Aktuell würde ich sagen es ist wirklich Go bzw. Golang oder wie man es auch immer nennt. Zumindest in der Betrachtung von Spaß am Programmieren, Produktivität und kann man Userinterface, Userfreundlichkeit bei Programmiersprachen sagen, wie man das anwendet. Also ich meine ich finde sie relativ einfach zu lernen im Gegensatz zu C++ zum Beispiel. Also ich glaube das ist eher so das Userinterface. Also in fremden Go-Code kommt man sehr schnell rein. Ich glaube, das ist so meine Begründung, warum es aktuell Go ist.

Wolfi Gassler (00:01:42 - 00:02:06)

Mir hätte jetzt ja wirklich gewundert, dass du so lange überlegt hast. Man hört das Überlegen ja nie, weil diese Pausen automatisch rausgeschnitten werden von unserer Software. Alles ganz klar, du als Go-Fanboy. Aber was wäre jetzt, wenn dein Team sagen würde, JavaScript ist viel besser und wir machen jetzt alles nur mehr in JavaScript oder TypeScript, weil es ist die Zukunft. Alles ist nur mehr in TypeScript. Go ist irgendeine Backend, komisches Zeug, braucht kein Mensch. API ist nur mehr alles in Node.js.

Andy Grunwald (00:02:07 - 00:02:36)

Ich glaub, das wär ein sehr guter Trainingscase für mich, um mich in Geduld und ... nicht Geduld, Geduld ist vielleicht das falsche Wort, aber um mich in Professionalität zu üben. Also, ich persönlich privat kann ich mit JavaScript jetzt nicht so viel anfangen, geb ich zu. Aber ich glaub, es ist eine unglaublich gute Exercise, da mal durchzugehen und konstant zu fragen, was ist eigentlich das Problem, welches durch JavaScript beziehungsweise TypeScript dann gelöst wird.

Wolfi Gassler (00:02:36 - 00:02:50)

Okay, probieren wir es noch ein bisschen zu verschärfen. Du bist in einer Firma, arbeitest da an Go und dann entscheidet der CTO, wir steigen jetzt auf JavaScript um, ist unsere Hauptsprache. Alle unsere APIs werden auf Node.js und TypeScript umgestellt. Würdest du kündigen?

Andy Grunwald (00:02:51 - 00:03:21)

Nein, ich würde nicht auf Basis von der Programmiersprache kündigen, auch wenn ich privat damit aktuell nicht so viel arbeiten würde. Ich würde dafür nicht kündigen. Ich würde den ganzen Sachen wirklich eine Chance geben und schauen, ob sich dann die Argumentation vom CTO bewahrheitet hätte. Und das sag ich jetzt nicht nur, weil wir hier im Podcast sind und so weiter, weil ich denke, dass Programmiersprachen kommen und gehen und Technologien kommen und gehen. Und ich denke, als professioneller Softwareentwickler sollte man auch da drüber stehen und nicht immer nur seine eigene Liebe nach vorne stellen.

Wolfi Gassler (00:03:23 - 00:03:55)

Du bist so ein guter Arbeitnehmer. Das ist unglaublich. Und damit sind wir jetzt schon aktuell voll im Thema drin. Denn heute geht es um Konsolidierung und Konsolidierung von Technologien. Ziemlich schwieriges Thema. Und was ich da so skizziert habe, passiert ja durchaus sehr oft. Ob jetzt Go gerade ersetzt wird im API-Bereich durch JavaScript, keine Ahnung. Aber zumindest in ähnlicher Form passiert es sehr, sehr regelmäßig und ist, glaube ich, auch ein großes Problem. Vor allem, wenn man Auf der anderen Seite ist diese Technologie, die vielleicht konsolidiert wird und abgeschafft wird.

Andy Grunwald (00:03:55 - 00:04:37)

Ich habe das Gefühl, das ist ein Thema, da gibt es nicht nur Gewinne. Also ich habe wirklich das Gefühl, bei diesem Thema verlieren mehr Leute, als Leute gewinnen. Und der Grund ist, dass das ja ein sehr emotionales Thema ist. Also ich meine, prinzipiell geht es um die Frage, sollten wir, und wir meine ich das Team, Abteilung, die Firma, unsere Technologien, sei es Programmiersprachen, Frameworks, Clouds, Runtime Environments, firmenweit oder projektweit konsolidieren das bedeutet wir haben einen technologie ansatz oder sagen wir jedes team jeder abteilung jedes produkt jedes projekt darf die technologien selber wählen das ist die grundfrage und dann auch was ist eigentlich besser in welchen bereichen.

Wolfi Gassler (00:04:37 - 00:04:42)

Hast du bisher gearbeitet hast du persönlich oder was was schätzt du persönlich mehr.

Andy Grunwald (00:04:42 - 00:04:55)

In meiner ersten firma war das eher so ein technologie stack ansatz Weil das dann viel mehr Typo 3 war und PHP und MySQL, ja? Da gab's noch damals diese Webposter, wo du das alles mit FTP hochladen konntest.

Wolfi Gassler (00:04:55 - 00:05:02)

Damals hat's nur keine anderen Programmiersprachen gegeben, da war PHP die große, hippe Sprache. Da gab's kein Go.

Andy Grunwald (00:05:02 - 00:05:52)

Ja, da gab's auch kein Kubernetes und Cloud war da halt auch noch nicht ganz so viel, ja? Also, da war der. Danach bei Trivago ... Und bei Trivago war eher halt schon sehr stark dieser Alles-ist-möglich-Ansatz. Also, jedes Team kann mehr oder weniger frei wählen. Kommen wir gleich noch zu. Und inzwischen in der aktuellen Firma ist es wieder sehr, sehr stark ein Ein-Technologie-Ansatz, aber aus einem anderen Aspekt heraus. Kann ich später auch noch mal drauf eingehen. Und es ist wirklich so, beide Ansätze haben bis zu einem gewissen Grad Vorteile und beide Ansätze haben bis zu einem gewissen Grad Nachteile. ich würde jetzt gar nicht sagen ich lehne mich in die ein oder andere richtung ich glaube wenn man von der einen richtung kommt und die andere richtung wechselt ist es erst mal sehr erfrischend und denkt sich wow man ist so in der richtung in der honeymoon phase und ja warten wir mal ab wenn man wenn man ganz lange in einem in einem bereich wieder ist.

Wolfi Gassler (00:05:53 - 00:06:30)

Man muss ja auch dazusagen, das sind die zwei Extreme. Es gibt das Extrem, alles ist möglich, ich darf jede Software verwenden, die ich will und kann von heute auf morgen irgendeine Sprache hinzufügen in meinem Stack. Das einfach machen. Und es gibt das andere Extrem, der Stack ist absolut fixiert, ich darf überhaupt nichts machen und brauche das Agreement vom CTO, damit ich überhaupt mal was ausprobieren darf. Es gibt ja auch sehr viel dazwischen, aber besprechen wir mal die Extreme, wenn wir die Extreme ansehen, um einfach mal so zwei Enden der Skala zu definieren. Wo siehst denn du die Vorteile von einem Alles-ist-möglich-Ansatz?

Andy Grunwald (00:06:30 - 00:06:53)

Naja, also prinzipiell ist ein Mega-Vorteil die Autonomie. Also ich meine, du stellst das Software-Engineers ein, damit die Software schreiben und du stellst diese Personen ja ein, damit die einen Job machen, den du nicht mehr machen kannst oder gegebenenfalls keine Zeit hast. Und mittels dem Alles-ist-möglich-Ansatz können die Software-Ingenieure wirklich entscheiden, was sie denn für ihre Arbeit einsetzen.

Wolfi Gassler (00:06:53 - 00:07:09)

Man muss ja dazu sagen, das ist ja der klassische Ansatz, genau wie du gerade erwähnt hast. Du bist vielleicht ein Founder, ein kleines Startup und brauchst jetzt einfach möglichst schnell Leute, die irgendwie Probleme lösen. Und dann ist dir das komplett egal, was für Sprachen die verwenden. Und du willst nur mal Leute, die dir dein Problem lösen.

Andy Grunwald (00:07:09 - 00:07:34)

Ja, das ist glaube ich ein zweiter Vorteil, weil dein Vorteil, den du gesagt hast, der geht eher auf Speed und Produktivität und besonders in der Anfangsphase. Was aber ich meine ist, dass du wirklich den Fachleuten die Entscheidung überlässt. Ich meine, du zahlst denen einen Haufen Geld und dann schreibst du denen alles vor, was sie zu nutzen haben. Also es ist wirklich so, dass man da vielleicht sogar sagen könnte, du kannst jetzt wirklich mal das richtige Tool für den richtigen Job nehmen.

Wolfi Gassler (00:07:34 - 00:08:02)

Du setzt jetzt aber voraus, dass die Leute das soweit wissen und nicht ihre Lieblingssprache verwenden, weil wenn die einfach seit 30 Jahren Java gemacht haben, dann verwenden die einfach Java. Das muss gar nicht das richtige Tool sein, sondern die verwenden Java, weil sie am produktivsten sind. Ist auch ein Vorteil. Du bist am produktivsten in deiner Sprache, die du lange gemacht hast und kommst jetzt in ein Team, musst irgendein Problem lösen, nimmst deine Sprache. obwohl die vielleicht im team noch gar nicht verfügbar ist also verwendet wird ja.

Andy Grunwald (00:08:02 - 00:09:05)

Natürlich ich gehe davon aus dass das hiring vorher schon ordentlich war dass du dass du talentierte leute hast dass du dass du leute hast die mit deiner mit deiner kultur und mit deiner mit deinem mindset irgendwie einhergehen ich sage nicht dass du ein homogenes team haben solltest ja das soll schon schon heterogenen divers sein etc etc, Doch Leute mit gesundem Menschenverstand. Und gesunde Menschenverstand meine ich jetzt wirklich, vielleicht nicht das einsetzen, was für ihre Karriere am wichtigsten ist, sondern für das Business. Aber die zweite Sache, die du gesagt hast, ist ja der Entwicklungsspeed. Wenn du Leute hast, die sich nicht mit MySQL auskennen, sondern nur mit Postgre oder nur mit DynamoDB, dann können die DynamoDB nehmen und sind einfach superproduktiv. Die kriegen einfach Get Shit Done. Und das willst du natürlich auch in irgendeiner art und weise besonders wenn du was neues aufbaust ja du willst schnelle ergebnisse sehen du willst schnell schnell schnelles movement haben du willst die investoren vielleicht irgendwie überzeugen mit einer demo oder neues feature bringen damit du mehr kunden kriegst also das ist schon schon ein riesen vorteil.

Wolfi Gassler (00:09:06 - 00:09:32)

Sogar wenn du vielleicht einen Schritt zurück gehst, du musst dir die Leute überhaupt mal erst bekommen, die dir deine Probleme lösen. Und wenn du keine Einschränkung auf die Datenbank hast, weil du sagst, okay, ist mir scheißegal, was wir Datenbank für verwenden, dann kannst du natürlich im MySQL Pool und im Postgres Pool fischen und musst dich nicht auf eine Seite schlagen und hast dadurch einfach mehr Möglichkeiten. Also darum glaube ich auch in der Startup-Phase sehr, sehr beliebt, weil du halt einfach losstarten kannst.

Andy Grunwald (00:09:33 - 00:10:15)

Ja, und ich glaub, ein Megavorteil ist auch so ein bisschen der Spaß am Job. Weil immer, wenn ich mit Leuten spreche und die Frage hör mal, warum hast du eigentlich mit Softwareentwicklung angefangen? Ich mein, Softwareentwicklung ist eigentlich superfrustrierend, ja? Du sitzt den ganzen Tag vorm Rechner, acht Stunden lang auf deinem Popo. Okay, inzwischen vielleicht stehst du auch, weil du ein Standing-Desk hast, aber ... Du hackst da irgendwelche Hieroglyphen in den Screen rein und drückst auf Compile, nachdem du zwei Stunden lang durchgecodet hast, und dann schreit der Computer dich an und sagt, da fehlt ein Semicolon. Also, wenn du es so siehst, ist das halt schon sehr, sehr frustrierend. Oder du programmierst irgendwas, funktioniert nicht, füllst es dreimal aus und es funktioniert. Also, das ist ja schon frustrierend. Aber auf jeden Fall sagen immer alle Leute, ja, ich hab Spaß am Erstellen, ja, ich möchte was erschaffen.

Wolfi Gassler (00:10:16 - 00:10:28)

Also Hacker News Driven Development, wie du es immer so schön nennst. Ich springe auf die nächste Datenbanktechnologie auf, weil die löst uns jetzt wirklich alle Probleme. Und am Ende hast du 30 verschiedene Datenbanken im System.

Andy Grunwald (00:10:29 - 00:11:01)

Ja also man man kriegt halt schon durch durch den durch den alles ist möglich ansatz schon sehr viel spaß beim entwickeln man hat konstant neue experimente vor sich man sieht sehr viel kram und kann sehr viel ausprobieren und dann natürlich das kommt einem natürlich in der in der in der späteren karriere unglaublich zugute ja du kannst natürlich dann bei werbesgesprächen oder du kannst fast überall mitreden du kannst sogar sehr gut punkten Und Leute, die einen kleineren Bullshit-Filter haben, die kannst du sehr schnell durch deine technische Expertise überzeugen. Weil du bist der T-Strich auf dem T-Shaped.

Wolfi Gassler (00:11:01 - 00:12:07)

Wobei man natürlich sagen muss, es kommt drauf an, wo du dich bewirbst. Weil wenn du dich bei irgendeiner Firma bewirbst, die eben genau den Stack definiert hat, nur Java will, die will dann einen Java-Profi. Wenn du da herkommst und sagst, ja, ich hab Go-Erfahrung, JavaScript-Erfahrung, Rust-Erfahrung, Python hab ich auch noch viel gemacht und ... Weiß der Geier, was noch? Diese Lebensläufe, wo dann so 40 Programmiersprachen oben stehen. Ich hab den Fehler ja am Anfang auch begangen. Ich hab alle Programmiersprachen in meinen CV geschrieben, die ich irgendwann mal verwendet habe. Und nachdem ich lange Zeit an der Uni war, verwendet man da halt sehr viele Programmiersprachen. Was heißt verwenden? Man hat sie mal irgendwie in einem Skript mal ausprobiert oder mal getestet und ist absolut kein Profi drin. und schreibt sie dann in den CV und dann stehen dazu 40 Sprachen. Und wenn ich von der anderen Seite komme, von der Hiring-Manager-Seite, das war für mich immer ein Klassiker, es kann sich niemand richtig in zehn Sprachen auskennen. Also wer kennt sich wirklich gut in mehr als zwei, drei Sprachen aus? Das ist ja fast eine Unmöglichkeit, meiner Meinung nach. Also es kommt schon darauf an, wo du dich bewirbst.

Andy Grunwald (00:12:07 - 00:12:09)

Es gibt aber auch Firmen, die suchen den Jack-of-all-Trades.

Wolfi Gassler (00:12:09 - 00:12:13)

Natürlich, Startups, Fullstack, wie man es auch immer nennt.

Andy Grunwald (00:12:14 - 00:12:28)

Und den Tiefgang brauchst du ja auch nicht immer, muss man ja auch ehrlicherweise sagen. So nach dem Motto, diese Whiteboard-Coding-Interviews, wo du Algorithmen irgendwie optimieren musst und dann im Job, weiß ich nicht, Inputfelder für ein Kontaktformular schreiben musst. Also das passt halt auch nicht, ne?

Wolfi Gassler (00:12:28 - 00:12:30)

Ja, der schreibt alle Copilot mittlerweile.

Andy Grunwald (00:12:30 - 00:12:46)

Wo lebst du? Also natürlich ist das immer so eine Frage, wo bewirbt man sich und wen hat man da gegenüber sitzen, denn auch Leute mit einem guten Bullshit-Filter, die können natürlich sehr schnell herausfinden, wie viel Tiefgang du hast. Also wie viel der vertikale Strich vom T, wie viel Tiefe ist denn da?

Wolfi Gassler (00:12:47 - 00:12:57)

Wenn wir jetzt mal auf die andere Seite gehen, auf die Nachteile Seite, siehst du irgendwo Nachteile auch? Jetzt klingt das alles sehr positiv und wenn wir Startups machen, dann muss das die ideale Seite sein.

Andy Grunwald (00:12:57 - 00:14:09)

Ja, ich denke am Anfang sieht man die Nachteile eigentlich nicht. Ich denke die Nachteile kristallisieren sich wirklich über eine gewisse Zeit hinaus. Also wenn das Startup nun sechs Monate am Start ist und einfach entwickelt, entwickelt, entwickelt und dicht gemacht wird, da könnte man sagen, hör mal, pass mal auf, wir waren sehr schnell, wir haben ein Produkt validiert, hat nicht geklappt, weiter geht's. Ja, da sieht man die Nachteile nicht. Ich denke, die Nachteile kommen wirklich nach einer gewissen Zeit. Und da habe ich das Gefühl, wird's umso schmerzhafter. Besonders, wenn es in Bereiche geht, wie Arbeiten an verschiedenen Services. Es wird deutlich schwieriger, besonders im Backend, sich in diverse Sprachen einzuarbeiten. Zum Beispiel eine Microservice-Agentur, wollte ich grad sagen. Eine Microservice-Architektur. Und dann muss ich einen Bug fixen, und dann muss ich erst was im Python-Microservice bauen, und danach im Go, und der Database-Connector ist dann in TypeScript geschrieben. Also, das ist unglaublich schwierig, weil du musst halt irgendwie dich in drei Sprachen bewegen, und bist dann nicht der Experte, und dann kommt vielleicht noch eine Type-Conversion mit Float, Precision dazu, und dann musst du wirklich schon verstehen, okay, wie konvertiert ihr denn jetzt TypeScript und Python? Ah, schwierig, auch die Kontext-Switcher, echt ermüdend.

Wolfi Gassler (00:14:09 - 00:14:41)

Also drei Sprachen gehen ja noch, find ich. Aber du musst ja noch die ganzen Levels mitrechnen, die du zusätzlich noch hast durch Frameworks, durch das Tooling, alles, was rundherum ist. Also die Sprache an sich ist vielleicht gar nicht das Problem, aber was so eine Sprache alles noch mitbringt an Framework, Tooling. Und da wird's dann schwierig, weil das wird ... dann schon auf mehrere Dimensionen komplexer. Und da wirklich mitzuhalten und dich gut auszukennen, das wird dann schwierig, meiner Meinung nach, ab drei Sprachen. Und da geht die Produktivität dann auch nach unten, im Endeffekt, wenn das System groß genug ist.

Andy Grunwald (00:14:42 - 00:15:07)

Naja, ich glaub, es kommt halt auch drauf an, welche Sprache. Also hast du Haskell im Stack und benutzt irgendwie nur Monaden. Du merkst schon, das versteht halt schon kaum jemand. Ist halt immer so der Running-Gag in der Programmier-Community. Dann wird's halt auch sehr schwer. Wenn du wirklich objektorientierte Programmierung mit funktionaler Programmierung vielleicht sogar mixt und du hast halt sehr viele Leute, die wenig Kontakt mit funktionaler Programmierung haben, dann ist auch zwei Programmiersprachen sehr hart.

Wolfi Gassler (00:15:07 - 00:15:40)

Ja, wenn die Konzepte ganz unterschiedlich sind, definitiv. Oder es gibt schon so Sprachen, die haben meiner Meinung nach eine schwierige Lernkurve, würde ich es mal nennen, so wie Rust. Da steigt man nicht schnell mal ein. Also JavaScript ist da vielleicht einfacher, obwohl mir jetzt vielleicht wieder viele auf die Füße steigen würden. JavaScript kann auch sehr, sehr schwierig sein. Aber der Einstieg erscheint zumindestens leichter, wenn man jetzt eine andere, wenn man aus der Python-Ecke zum Beispiel kommt oder aus der PHP-Ecke, dann kann man vielleicht schneller JavaScript programmieren, als man Rust programmieren kann oder C++.

Andy Grunwald (00:15:41 - 00:15:49)

Wenn wir schon bei schnellen Einstieg sind, geht es natürlich bei einem Nachteil auch um die Themen, wie kriege ich neue Leute, also Hiring, und wie trainiere ich die.

Wolfi Gassler (00:15:50 - 00:15:53)

Jetzt haben wir gerade gesagt, es ist leichter, Leute zu bekommen. Was meinst du?

Andy Grunwald (00:15:53 - 00:16:49)

Ja, in der Anfangsphase. Aber später, wenn das Produkt mal Traktion bekommt, mal User hat und so weiter, dann kriegst du natürlich auch ganz andere Probleme. Da kriegst du Probleme, wo du gegebenenfalls Experten in einer Technologie brauchst, die dir das ja dann lösen. Und das wird dann natürlich schwieriger. Wenn du jetzt nur einen Microservice hast, der in Python geschrieben ist, und du suchst jemanden, der sich mit dem Global Interpreter-Log ganz gut auskennt oder ähnliches, dann hast du halt einen Python-Experten geholt und gegebenenfalls sogar fest angestellt, Freelancer sind natürlich immer eine Lösung, aber gegebenenfalls fest angestellt, und dann ist die Frage, okay, können wir diese Person auch an einen Haskell-Service setzen? Und dann sagt die Person, ja, Hammer, du, pass mal auf, ich hab meine ganze Karriere aber eigentlich um Python gebaut, und ich würd gern auf diesem Pfad bleiben. Was ja völlig valide ist, aber da ist dann der erste Konflikt vorprogrammiert. Also es ist natürlich schwieriger, Leute zu finden bzw. Experten in einer Technologie zu bekommen, weil diese in einem Alles-ist-möglich-Ansatz natürlich auch sehr flexibel sein müssen.

Wolfi Gassler (00:16:49 - 00:17:13)

Wobei da argumentieren würde, wenn dann die Firma größer ist, dann kannst du halt auch Experten haben, die dann nur auf einer Technologie arbeiten, wenn du eine gewisse Größe erreicht hast. Also wenn du wirklich diese Spezialisten brauchst, hast du wahrscheinlich die Größe und kannst ihn dann nur auf ein Thema setzen. Aber klar, der hebt sich dann natürlich ab und sagt, naja, an dem anderen Zeug, da habe ich keine Ahnung, will ich nicht arbeiten. Also da kommen dann andere Probleme dann vielleicht im Team wieder auf.

Andy Grunwald (00:17:13 - 00:17:35)

Aber stell dir doch mal so Firmen vor wie WhatsApp. Ich glaube, WhatsApp wurde sehr lange gehypt. Weil die die komplette Infrastruktur irgendwie nur mit zehn Leuten maintainen und das ist ein weltweit genutzter Service. Und du sagst, wenn die Firma dann größer ist. Das ist halt die Frage, was ist dann größer? Ist das Mitarbeiter? Ist das Revenue? Ist das die Userbase oder die Infrastruktur? Also in so einem Setup wird es halt dann schwierig, finde ich. Mit Experten, die dann gegebenenfalls nicht flexibel sein wollen.

Wolfi Gassler (00:17:35 - 00:17:49)

Naja, aber du hast noch, wobei ich jetzt natürlich nicht weiß, ob WhatsApp wirklich die Experten gebraucht hat und einen sehr heterogenen Stack gehabt hat, aber du hast das Onboarding auch noch erwähnt, also das Weiterbilden der Leute. Was hast du damit gemeint, das Training?

Andy Grunwald (00:17:50 - 00:19:09)

Naja, Onboarding bei neuen Leuten, Training bei neuen beziehungsweise existierenden Leuten. Es ist halt einfach deutlich schwieriger und du musst die ganzen Leute natürlich auf einen deutlich größeren Stack produktiv kriegen. Wie gesagt, du hast dann Python, du hast dann JavaScript oder TypeScript, dann hast du Go und vielleicht noch ein Java und vielleicht noch ein Haskell Service und da hinten noch drei Datenbanken, SQL und NoSQL. Also gefühlt musst du dich mit allen Basis-Funktionalitäten dann von dem Stack aus kennen, denn natürlich kann man sagen, hey, du hast ja nur eine Microservice-Architektur und dann hast du Verträge zwischen den Services und du musst nur den Vertrag erfüllen, damit Service A mit Service B kommunizieren kann. Ja, alles nicht falsch, nur umso besser du als Software-Ingenieur sein möchtest, umso ein globalere Sichtweise musst du haben, was es eigentlich bedeutet für die ganze Architektur, wenn du diese Änderung machst. Und dafür musst du dir natürlich bewusst sein, mit welchem Stack du arbeitest und dafür und so weiter und so fort. Also, die Leute auf den großen Stack zu onboarden, ist natürlich dann über Zeit sehr herausfordernd und kann natürlich dann einfach wirklich in die Zeit und dann auch in die Kosten gehen. Was schätzt du? Bei einem Onboarding, bei einem komplett heterogenen Stack, wirklich verschiedene Datenbanken, verschiedene Microservice-Architekturen, vielleicht sogar verschiedene Loadbalancer Du hast ein Kubernetes, dann hast du ein Nomad und dann hast du noch einen Docker Swarm da und dann läuft es auf GCP und AWS. Was meinst du, wie lange brauchst du, um da einen globalen Überblick zu kriegen und einigermaßen sich produktiv in den Welten zu bewegen, zeitlich?

Wolfi Gassler (00:19:09 - 00:21:05)

Also meiner Meinung nach kommt es wirklich darauf an, wo du einsteigst, wenn du neu bist. Weil wenn du natürlich in einem sehr hohen Level einsteigst, wo du den Überblick brauchst, ist es schwieriger. Aber auch da würde ich sagen, es ist gar nicht unbedingt so technologiegetrieben, Da gibt es andere Schwierigkeiten, weil es halt einfach schwierig ist, einen Stack zu verstehen, auch wenn der nur eine Technologie hat, der 30 Teams umfasst. Wie bekommst du den Überblick? Wenn du jetzt in einem Team einsteigst, glaube ich, ist es einfach, den Überblick zu bekommen, weil du nur im Team arbeitest und in dem einen Team gibt es ja selten 30 Technologien. Das heißt, ein Team einigt sich ja meistens eher auf einen kleineren Kreis von Technologien. Darum bin ich mir gar nicht so sicher, ob dieses Onboarding-Argument so gilt, weil meiner Meinung nach in einem kleinen Team ist es gar nicht so das große Problem und da muss ich mich ja nur in dem einen Team zurechtfinden. Das können natürlich auch schon mehrere Technologien sein, je nachdem, aber ich glaube, das ist auf jeden Fall noch möglich. Was dann aber nicht mehr möglich wird und das ist dann natürlich auch das Problem bei größeren Firmen, wenn du irgendwann zwischen den Teams wechseln willst. weil dann hast du dich an einen Stack gewöhnt, an diese drei, vier, fünf Technologien in dem Team und dann wirst du wechseln und das andere Team verwendet eine komplett andere Technologie. Es ist vielleicht verständlich, okay, da ist ein Load Balancer, jeder versteht, was ein Load Balancer ist, der sich in dem Bereich auskennt, egal was das für eine Software, was für ein Tool das ist, aber dann das Umsteigen im Endeffekt und vielleicht eine neue Sprache, ein neues Framework, eine neue Load Balancer Technologie zu lernen, ist dann natürlich schon ein Aufwand. Hingegen, wenn du ein Single Stack hast, springst du da einfach ein anderes Team und weißt, okay, die verwenden genau den gleichen Load Balancer, genau die gleiche Datenbank, genau die gleiche Programmiersprache, genau das gleiche Framework und genau den gleichen Stack, um Sachen zu deployen. Und da bist du dann plötzlich schneller, wenn du springst. Und wenn du ein sehr homogenes Umfeld hast, ist es natürlich leichter als wie ein super heterogenes Umfeld mit tausenden Technologien.

Andy Grunwald (00:21:05 - 00:21:42)

Ich finde es unglaublich schön, in welcher Welt du lebst. Du redest grad von Teams, die maintainen immer nur einen Microservice oder einigen sich immer nur auf einen Stack bei einer wachsenden Firma. Bis die erste Reorg kommt, die erste Reorganisation, weil vorher hat man natürlich immer alles anhand von Conway's Laws aufgebaut, dass deine Microservice-Architektur nach deiner Infrastruktur aussieht. Aber du weißt doch selbst, wie's ist. Dann werden Teams geschaffelt, dann werden Verantwortungen neu gewürfelt, und auf einmal erbt ein Team nämlich drei Microservices zusätzlich, die natürlich dann einen anderen Stack haben. Und dann fällt natürlich dein Happy Pass Gedanke da, den du gerade vorgetragen hast, mal schön in sich zusammen.

Wolfi Gassler (00:21:42 - 00:22:27)

Ja, sage ich ja. Also wenn du zwischen Teams wechselst oder deine Teams austauscht, dann hast du natürlich genau dieses Problem. Aber das Onboarding ist meiner Meinung nach weniger ein Problem. Aber dann später, wenn es um Maintenance geht, um die ganzen Wechsel, da sind dann wirklich die Schwierigkeiten drin. Und wenn du dann plötzlich nach fünf Re-Orgs, 20 Technologien geerbt hast, dann wird es natürlich auch schwierig, dass du es mit einem Team überhaupt schaffst. Und wenn wir dann noch in die Richtung gehen von Buzzfactor, also wie viele Leute verstehen denn die einzelnen Technologien wirklich gut und du musst irgendwie ein Encore zum Beispiel aufbauen und dir fehlen aber die Leute dazu, die überhaupt die ganzen Technologien verstehen, dann hast du sehr schnell ein Problem. Also gerade im Wachstum, umso größer, umso schwieriger wird es dann. Da stimme ich dir voll und ganz zu.

Andy Grunwald (00:22:28 - 00:24:17)

Und einer der Nachteile, die oft übersehen werden, kommen so aus der Infrastrukturecke. Und zwar hat man in vielen Firmen inzwischen Plattformteams, DevOp-Teams, Betriebsabteilungen, Systemadministrator-Teams und so weiter und so fort. Oder inzwischen heißen die Developer Experience, die sich halt darum kümmern, dass Software-Engineers einfacher deployen können und sich um den ganzen Stack nicht kümmern müssen und nicht wissen, was da läuft und so. Und solche Teams haben natürlich dann ein Problem, die Frage zu beantworten, auf welche Technologien sollen sie sich eigentlich fokussieren. Also du hast jetzt vier, fünf Programmiersprachen, du hast jetzt sechs, sieben Runtime Environments. Das eine ist ein ganz normales JAR und das nächste ist ein Docker-Container und das dritte ist eine Technologie, die mir gerade nicht einfällt. Auf jeden Fall, auf was fokussieren die sich denn? Es ist halt eine schwierige, schwierige Frage. Und die zweite Geschichte, die damit einher spielt, wenn sogar nicht nur die Programmiersprachen und die Runtime Environments, doch sogar zur Wahl steht, wo man den ganzen Kram hostet, eigenes Datacenter, Google Cloud Platform, Amazon Web Service, Azure, Wurzel, Heroku, Dann geht's sogar richtig knallhart einfach nur ans Geld, weil am Ende vom Tag muss Service A mit Service B sprechen. Und wenn Service A in Google gehostet ist und Service B in Amazon und Service C in Wurzel, dann kommen da ganz klar einfach Traffic-Kosten auf einen zu, die man eigentlich sonst nicht hätte. Und nicht nur Traffic-Kosten, sondern auch realer Aufwand. Du musst Netzwerkverbindungen zwischen denen bauen, vielleicht sogar private Lines, private Link oder was weiß der Geier nicht, wenn du es nicht alles durch offenes Internet schicken möchtest. Und dazu kommt natürlich Verschlüsselung und blablabla, all das, dieser Riesen-Rattenschwanz, der da hinten dran hängt. Und das übersieht man halt oft, wenn man sagt, okay, das hier ist jetzt aber ein super Use-Case für Erlangen. Und das ganze Ding ist normalerweise in JavaScript gebaut.

Wolfi Gassler (00:24:18 - 00:24:29)

Als Davis Advocate würde ich jetzt natürlich sofort sagen, das schaffen wir als Team schon, wenn ihr da in der DevOps-Ecke zu schwach seid, das machen wir alles in unserem Team. Aber da kommen wir eh später noch dazu.

Andy Grunwald (00:24:29 - 00:24:37)

Sagte Wolfgang und schmiss das Deployment-Paket über die Wand und nahm sein Club-Handy und rufte die 1990er-Jahre an.

Wolfi Gassler (00:24:40 - 00:25:07)

Aber gehen wir mal weg von der einen Extremseite zur anderen Extremseite, also man darf alles, jede Technologie ist erwünscht, hin zum Extremfall auf der anderen Seite, wir haben nur eine Technologie oder zumindest einen super genau definierten Stack und nur das ist erlaubt. Kann man da jetzt sagen, da ist alles genau nur umgedreht, Vor- und Nachteile oder siehst du da irgendwie große Unterschiede?

Andy Grunwald (00:25:08 - 00:25:39)

Ja, die Nachteile vom Alles-ist-möglich-Ansatz sind jetzt hier die Vorteile und vice versa. Welcome to my TED-Talk. Das war unser Podcast. Vielen Dank. Bis zur nächsten Woche. Nein, so einfach ist es natürlich nicht. Ja, bei manchen Punkten sind die Nachteile vom Alles-ist-möglich-Ansatz die Vorteile von einem Technologieansatz. Das stimmt schon. Sowas wie Arbeiten über Teamgrenzen ist deutlich einfacher, weil alle denselben Stack nutzen. Hiring ist relativ einfach, weil relativ klar ist, was gesucht wird. Wenn ich einen Python-Stack habe, suche ich Python Software Engineers.

Wolfi Gassler (00:25:40 - 00:26:17)

Wobei dann natürlich schwierig ist, dass dein Teich, in dem du fischst, grundsätzlich kleiner ist. Also du suchst dann halt wirklich nur die Python-Leute und kannst eben nicht auch den Fullstack-Dev einstellen oder den jungen Developer, der gerade von der Uni kommt und sagt, hey, mit diesen alten, altbackenen Java-Bullshit möchte ich gar nichts mehr zu tun haben. Ich möchte irgendwie die hippe neue Technologie haben. Die fallen dir natürlich dann automatisch weg. Also dass Hiring automatisch einfacher ist, würde ich jetzt überhaupt nicht unterschreiben. Also es hat immer Vor- und Nachteile. Ich glaube, in beiden Ansätzen kann Hiring schwieriger und leichter sein, je nachdem von welcher Ecke man das Ganze sieht.

Andy Grunwald (00:26:17 - 00:26:30)

Okay, einfacher ist vielleicht das falsche Wort. Vielleicht kann man sagen, es ist deutlich klarer und spezifizierter, was gesucht wird. Und es ist, glaube ich, für beide Seiten Arbeitnehmer sowie Arbeitgeber deutlich transparenter, was dann auch gemacht wird im eigentlichen Job.

Wolfi Gassler (00:26:31 - 00:27:15)

Es ist viel einfacher, die Stelle zu definieren und wahrscheinlich auch die Interviews zu führen. Und es ist klarer, wenn du im Interview einfach sagen kannst, das ist unser Stack, du wirst auch mit diesem Stack arbeiten. Im Gegensatz zu, wir haben da fünf Teams, wir wissen noch nicht, wohin du kommst. Jedes Team verwendet einen anderen Stack. Du darfst auch deine eigenen Sachen machen. Wenn du erst in drei Monaten anfängst, könnte dieses Team aber schon wieder weg sein und der Stack weg sein und es könnte schon wieder eine andere Programmiersprache sein. Das ist natürlich auch viel Unsicherheit, die man da reinbringt, die nicht alle Kandidatinnen so gern wollen und so gern sehen, natürlich in einer Firma. Da ist da ein Technologieansatz für Leute, die seit 30 Jahren Java machen, unbedingt wieder Java machen wollen, natürlich viel einfacher, wenn die in so eine Firma umsteigen.

Andy Grunwald (00:27:15 - 00:28:21)

In Kombination mit dem Hiring sprechen wir natürlich auch über das Onboarding. Das kann einfach firmenweit standardisiert werden und es kann sogar über die Teams verteilt werden. Zum Beispiel in meiner aktuellen Firma verfolgen wir primär einen Ein-Technologie-Ansatz und immer wenn neue Leute starten, Die Onboarding-Sessions, also wir haben da so einen Onboarding-Plan und du machst die ersten paar Wochen Video-Sessions mit und allem drum und dran. Und diese Sessions werden wirklich, glaube ich, über sechs oder sieben Teams verteilt. Also das geht dann in so einer klassischen Rotation. Und somit hat natürlich jeder einen Incentive, das Onboarding-Material aktuell zu erhalten. Und das ist natürlich schon ein unglaublich großer Standard, dass nicht immer Leute zurückgehalten werden müssen pro Team, die dann ein Onboarding machen müssen. Und das dann natürlich immer und immer und immer wieder. Wechsel ist natürlich deutlich einfacher, da kaum ein neues Onboarding stattfinden muss. Man kann ja sagen, okay, der Stack ist gleich, sondern nur die Logik vom neuen Team ist ein bisschen anders. Und das ist natürlich ein unglaublicher Vorteil, wenn du, ich sage immer so schön, nur die Hälfte lernen musst. Du musst ja nur die Logik vom neuen Service lernen, aber nicht das Drumherum, weil das Drumherum kennst du ja schon von einem anderen Team.

Wolfi Gassler (00:28:22 - 00:28:36)

Und mit Maintenance und den ganzen Plattform-Teams ist es natürlich auch viel leichter. Sie können sich alle auf eine Sache konzentrieren. Man kann darauf aufbauen. Jeder kennt den Stack. Jeder weiß, wie deployed wird. Jeder weiß, was für Plattformen zur Verfügung stehen. Super easy alles.

Andy Grunwald (00:28:37 - 00:29:22)

Ich glaube, da bei dem Punkt kommt richtig, richtig Geld und Produktivität ins Spiel. Besonders, wenn sich Plattform-Teams, Developer-Experience-Teams auf Schnittstellen konzentrieren können, wie Logging, Tracing und das Tooling, wirklich um eine Sprache herum, dann kann das die Produktivität von Software-Engineering-Teams unglaublich boosten, weil die sagen einfach, okay, pass mal auf, da hinten, das Developer-Experience-Team hat einfach eine Tracing-Library für Python rausgebracht, die binde ich einfach ein und die funktioniert einfach. Das bedeutet, das In-House-Tooling kann einfach genutzt werden und du hast einfach, einfach in Anführungszeichen natürlich, einen kompletten Stack mit Observability und Debugging und whatnot, was du da alles gebaut hast?

Wolfi Gassler (00:29:22 - 00:29:42)

Du lebst aber auch in deiner heilen Welt, oder? Wenn ein anderes Team deine Library entwickelt hat, dann ist das doch die Library von diesem anderen Team. Das werde ich als schlauer Developer nie im Leben einsetzen, weil ich kann das besser. Und ich kann da meine eigene Technologie verwenden und eine bessere Technologie verwenden als dieses andere Team. Also, das ist ja absolut kein Argument. Definitiv nicht.

Andy Grunwald (00:29:42 - 00:29:49)

Ich glaube, das, was du gerade gesagt hast, ist der Grund, warum Berlin einer der Top-Startup-Städte in Europa ist und nicht Innsbruck, oder?

Wolfi Gassler (00:29:49 - 00:29:50)

Jetzt bin ich auf die Connection gespannt.

Andy Grunwald (00:29:51 - 00:29:55)

Ja, Innovation, Produktivität. In Innsbruck wird immer alles neu entwickelt, oder?

Wolfi Gassler (00:29:56 - 00:31:13)

Ja, wir sind halt innovativ, genau. Hast du vollkommen recht. Aber da sind wir gerade bei einem sehr guten Thema, das haben wir nämlich bei dem Alles-ist-erlaubt-Ansatz gar nicht so besprochen. Du nimmst dir natürlich schon eine Möglichkeit, wenn du nur einen Stack erlaubst und eine Technologie und das ganz hart auch durchsetzt, dass du innovativ bist. Weil wenn du natürlich keine Leute hast, die mal gern was ausprobieren, du erlaubst es vielleicht auch gar nicht, dass die Leute was ausprobieren, wie willst du denn dann mit der Zeit gehen? Also es ist dann natürlich super schwierig, wenn du seit 30 Jahren Java gemacht hast, irgendwann mal zu sagen, okay, wir probieren mal was anderes aus. Weil das funktioniert ja alles so perfekt und irgendwann bist du dann an diesem Punkt, wo dir dann die ganzen BewerberInnen ins Gesicht sagen, Moment, habt ihr keine neuere Technologie, keinen neueren Stack? Wo seid ihr? Warum arbeitet ihr noch mit dem? Und da ist es dann schon schwierig, überhaupt die Leute zu bekommen, die ein bisschen innovativer sind, die was Neues reinbringen in die Firma. Und für die Firma ist es natürlich selbst schwieriger, innovativ zu sein. Und man wird halt dann vielleicht einfach von der Industrie links und rechts überholt von diesen Startups, die alles erlauben, weil man selber einfach als unattraktiver Arbeitgeber gesehen wird, alte Technologie verwendet und den Absprung verpasst hat. Und das ist, glaube ich, die größte Gefahr, wenn man so ganz stur auf den Ein-Technologie-Ansatz setzt. Und das ist eine Riesengefahr, die man, glaube ich, immer mitdenken muss.

Andy Grunwald (00:31:13 - 00:31:32)

Ich bin mir nicht sicher, ob innovativ so das richtige Wort ist, denn Innovation kann sehr viel sein. Ich denke, experimentierfreudig ist so ein besseres Wort in der Hinsicht. Also wirklich Proof of Concept zu machen, das skaliert etwas besser, löst das wirklich ein Problem durch Testansätze. Und wenn du jetzt natürlich, ja, wie du sagtest, nur Ein-Technologie-Ansatz hast, dann wird das natürlich geblockt.

Wolfi Gassler (00:31:32 - 00:32:08)

Ja, außerdem, wie willst du innovativ sein, ohne mal was auszuprobieren? Also auch, sogar wenn du im gleichen Stack bleibst innerhalb von Java, du musst experimentierfreudig sein, was ausprobieren, damit du überhaupt eine Innovation, auch innerhalb von dem alten Java Stack zum Beispiel, kannst du ja genauso innovativ sein. Aber auch da musst du Sachen ausprobieren und da muss dir Zeit zur Verfügung gestellt werden im Team und die Möglichkeit und nicht, hey, wir haben doch diese Pipeline, die funktioniert und die wurde mal aufgesetzt vor zehn Jahren und warum sollten wir da jetzt was ändern. Investiere gefälligst die Zeit in deine Hauptarbeit und spiel da nicht irgendwo an irgendeiner Pipeline herum, um da was zu erneuern.

Andy Grunwald (00:32:09 - 00:34:17)

Ja, das stimmt schon, wenn man 100 Prozent pennt und wirklich gegen alles Neue ist, dann kann das schon wirklich ein Problem werden, dass die Industrie dich wirklich überholt. Man muss aber auch sagen, nicht alles, was die Industrie rausposaunt, ist geil. Aber es geht ja immer gar nicht um Fakten in der Hinsicht, sondern nur, wie wird das angesehen? Denn was auch sein kann, ist, dass andere Leute deinen einen Technologieansatz bereits als Legacy abstempeln, weil du noch auf einem JavaScript-Framework vor drei Monaten bist und nicht von heute. Und das kann natürlich dann ein reales Problem werden, wenn einfach keine Leute mehr bei dir anfangen wollen auf Basis deines Stacks. Und da muss es gar nicht nach Innovation und Experimenten gehen, sondern wirklich, oh, ihr benutzt keine moderne Technologie, wie wollt ihr denn jetzt hier überleben? Eine kleine Story aus Trivago, die habe ich mal gehört, da muss ich zugeben, ich weiß nicht, ob das wirklich jetzt ein Grund war oder nicht. Ja, das, also Disclaimer, hab ich mal gehört, dass das, war so Flurfunk sozusagen, aber kann ich schon ein bisschen nachvollziehen, dass das so wahrgenommen wird. Und zwar ist beziehungsweise war Trivago ein unglaublich großer Nutzer von Hadoop. Wer kennt Hadoop noch? Dieser Big-Data-Stack mit diesem Elefanten, ja? HDFS-Filesystem und so weiter und so fort. Und meist hat man das On-Premise eingesetzt. Es gibt so viel. Ich weiß, Amazon hat auch so ein Hadoop-Service. Elastic Map and Reduce heißt das, glaub ich. Auf jeden Fall wird das halt als Data Warehouse in der Regel eingesetzt. Und obendrauf kannst du natürlich diverse Technologien setzen, auch SQL-basierte Technologien, um natürlich deine Datenanalyse auf deinem Data Warehouse zu machen. Und was braucht man dafür? Eine ganze Menge Data Scientists. Wenn du Sinn aus deinen Daten machen möchtest, dann brauchst du natürlich eine ganze Menge Data Scientists. Und die aktuellen Data Scientists, die werden mehr und mehr und mehr auf BigQuery geschult. Das bedeutet mit dem SQL-Dialekt, mit den kleinen Details von BigQuery und so weiter und so fort. Schon so einen kleinen Effekt aufs Hiring, weil du hast halt kaum Data Scientists gefunden, die noch mit in Anführungszeichen altem Stack wie Hadoop arbeiten wollen. Oder Leute, die frisch im Data Science Bereich waren, die keine Erfahrung mit Hadoop hatten, sondern nur mit BigQuery und dann natürlich auch ihre Karriere drum. bauen wollen.

Wolfi Gassler (00:34:17 - 00:34:48)

Oder Spark zum Beispiel, um jetzt nicht nur irgendein Cloud-Angebot zu nennen, aber Spark geht ja in die ähnliche Richtung. Und klar, man hat da so eine Trendwende in Richtung SQL gesehen damals, finde ich natürlich sehr cool, nach dieser NoSQL-Geschichte ist schon sehr viel wieder in SQL gegangen und heute wird, glaube ich, wesentlich mehr im Data-Science-Bereich mit SQL wieder gemacht. als noch vor ein paar jahren und das passiert halt wirklich innerhalb von ein paar jahren und wenn man da nicht aufpasst und nicht mit der zeit geht geht man mit der zeit wie es so schön heißt natürlich haben wir jetzt.

Andy Grunwald (00:34:48 - 00:34:57)

Ein paar nachteile erwähnt die natürlich 100 prozent als extrem angesehen werden ja dass du gar keine proof of concept und neue technologien rein lässt muss nicht so.

Wolfi Gassler (00:34:57 - 00:35:07)

Sein kann aber jetzt sprechen wir von wie kommt man vom alles ist möglich ansatz zu diesem ein technologie ansatz ist das ziel oder unser ein technologie ansatz Habe ich das richtig verstanden?

Andy Grunwald (00:35:07 - 00:35:09)

Das ist immer das Ziel.

Wolfi Gassler (00:35:09 - 00:35:29)

Also das wird jetzt eine Beratungsepisode für CTOs, wie komme ich von diesem Chaoshaufen-Startup zur Ein-Technologien-Ansatz, weil es ist das absolute Ziel. So arbeiten zumindest alle Firmen, wenn man sich das so ansieht, weil die ganzen alten Firmen haben den Ein-Technologie-Ansatz in Alpbacken, keiner will mehr dort arbeiten, so läuft es doch, oder?

Andy Grunwald (00:35:30 - 00:35:50)

Soviel ich weiß ist das auch der aktuelle Trend bei den Startups, aktuelle wirtschaftliche Situation ist gerade etwas herausfordernd, Geld ist gerade nicht mehr so günstig, Wachstum ist jetzt gerade nicht mehr Prio 1, sondern jetzt ist Effizienz und Produktivität die Nummer 1. Und was läuft da besser als ein Technologieansatz? Wie machen wir es? Computer Rewrite und Go? Ja oder?

Wolfi Gassler (00:35:50 - 00:35:52)

Go ist doch auch schon altbacken oder?

Andy Grunwald (00:35:53 - 00:36:03)

Kompletter Rewrite und Go, da war jetzt nicht Go die Sprache genannt, sondern und los geht's. Ah, okay. Aber kommen wir mal ganz kurz zu ...

Wolfi Gassler (00:36:03 - 00:36:10)

Der Bandbreite dazwischen, würde ich mal sagen, und vor allem die Konflikte, die auch entstehen zwischen diesen zwei Seiten.

Andy Grunwald (00:36:10 - 00:36:31)

Konflikte ist ein schönes Wort, weil besonders, wenn man darüber spricht, welche Sprache man einsetzen möchte, Das sind ja Diskussionen wie Wim oder Emacs, wie Tabs oder Whitespaces, wie Windows, Linux oder Mac, wie Android oder iOS. So nach dem Motto, da gibts halt richtig auf die Schnuss, richtig gut, ein schöner Boxkampf, sogenannte Language Wars.

Wolfi Gassler (00:36:33 - 00:36:51)

Du nennst es jetzt Language Wars, manche andere nennen das Tech-Culture. Wir erlauben alles. Wir erlauben, was für Betriebssystem du verwendest, was für ein Computer du verwendest, was für Technologie du verwendest, was für eine Methodik du verwendest, Scrum, Kanban, whatever, Wasserfall, wir erlauben einfach alles. Es ist Tech-Culture, Andi.

Andy Grunwald (00:36:51 - 00:37:19)

Und ja, ein Alles-ist-möglich-Ansatz kann auch als Tech-Kulturelement verkauft werden. Und ich bin ja auch nur ein Mensch. Für mich, als ich ein paar Jahre im Job war, drei, vier Jahre, war das auch ein Element oder ein Entscheidungskriterium, weil ich wollte ja viel sehen, ich wollte ja Erfahrungen sammeln. Inzwischen denke ich mir, ob das jetzt so die hundertprozentige richtige Art und Weise ist, weiß ich jetzt auch nicht mehr. Aber ich kann schon, ich kann schon verstehen, warum das als Hiringgrund oder als Techkultur mit reingenommen wird, aber es ist schwierig.

Wolfi Gassler (00:37:19 - 00:37:33)

Und warum, warum hast du dann, wenn du jetzt eh auf dieser eine Technologie Seite bist, warum hast du dann deine Linux Maschine austauschen lassen, deinen Firmen Laptop zu einem Mac und bist dann nicht der Policy gefolgt?

Andy Grunwald (00:37:33 - 00:37:37)

Das ist relativ einfach. 2023 ist immer noch nicht das Jahr des Linux Desktops.

Wolfi Gassler (00:37:38 - 00:37:51)

Du willst jetzt nur rausreden, einfach. Auch weil du im Mac gewohnt warst, im Mac schneller bist und darum produktiver am Mac und darum wolltest du unbedingt auf dem Mac zurück. Gib's doch zu. Du bist jetzt auch schon alt. Das ist wie die alte Java-Technologie.

Andy Grunwald (00:37:51 - 00:38:15)

Na, das war einfach technische Hürden. Als ich gestartet bin, gab's halt noch nicht die Möglichkeit, unseren Code auf einer ARM-Architektur laufen zu lassen. Inzwischen wurde das natürlich technisch gelöst, deswegen bin ich einfach mal von Linux auf. Mac gewechselt. Ja, es gibt auch inzwischen Linux ARM Laptops, stimmt schon, aber ich hatte einen x86 Laptop, von daher. Und ich weiß nicht, aber irgendwie ... Sprechen wir über Languageforce oder über Linux versus Mac jetzt?

Wolfi Gassler (00:38:15 - 00:38:26)

Ja, ist ja eigentlich dasselbe, oder? Aber ich erkläre dir dann irgendwann einmal, wenn wir uns wieder treffen, zeige dir das, wie das mit dieser Konsole und einem Terminal funktioniert, was man da so machen kann auf dem Linux ohne Clicky-Bunty.

Andy Grunwald (00:38:26 - 00:38:29)

Und ich zeige dir dann, wie der Audio-Driver funktioniert, oder?

Wolfi Gassler (00:38:29 - 00:38:39)

Genau, wenn du in das rechte obere Eck fährst und dann irgendwas Magic passiert auf dem Mac. Mit dem habe ich mich nie anfreunden können, ich habe einen Mac verwenden müssen damals bei Trivago und wollte eigentlich Linux.

Andy Grunwald (00:38:39 - 00:39:27)

Aber ihr merkt schon worum es geht, da kommt wirklich die richtige Passion von Software Engineers raus, da kommen Emotionen raus, starke Präferenzen. Und das ist natürlich faszinierend zu beobachten. Es schadet natürlich auch sehr viel, weil sehr viel Energie auf etwas verschwendet wird. was es mit hoher Wahrscheinlichkeit nicht wert ist, aber wenn man sich da einfach mal zur Seite setzt und das beobachtet, finde ich es faszinierend, also wirklich menschlich faszinierend, wie viel Energie in so etwas gesteckt werden kann, wenn jemand von seiner Sache überzeugt ist. Und als Engineering Manager frage ich mich natürlich immer, wie kann man diese Energie und diese Passion und diese Motivation kanalisieren auf das, was wir zusammen erreichen wollen. Also wer das schafft und wer mir sagen kann, wie das geht, Also ich würde gerne diese Motivation und Passion und Energie wie bei Language Wars haben.

Wolfi Gassler (00:39:27 - 00:39:44)

Ja, du sagst es schon ganz richtig, als Außenstehender, als Engineering Manager sieht man diese Dinge ja ganz ganz anders, als wenn man in diesen Language Wars oder Technology Wars drin ist. Mein Wars klingt übrigens immer wie Arnold Schwarzenegger, ich finde das schrecklich, aber ich kann das gar nicht verbessern.

Andy Grunwald (00:39:45 - 00:39:50)

Kurzer Einwand, du bist einfach eine Bodenstange, du bist ein Lauch gegenüber Arni.

Wolfi Gassler (00:39:50 - 00:39:51)

Der stimmt natürlich.

Andy Grunwald (00:39:51 - 00:39:57)

Language Wars. Kannst du Language Wars mal richtig hart mit österreichischem Dialekt sagen bitte?

Wolfi Gassler (00:39:57 - 00:39:58)

Sag ich das nicht eh schon?

Andy Grunwald (00:39:59 - 00:40:00)

Gib dir mal Mühe.

Wolfi Gassler (00:40:00 - 00:40:56)

Language Wars, bin da gar nicht so gut drin, aber ich glaube es kommt schon mit natürlicher Dialekt gut genug durch. Aber kommen wir mal zur Konsolidierung. Also wenn du auf der Engineering-Manager-Seite bist oder CTO oder was auch immer, dann hast du ja mit dem zu tun, dass du irgendwann konsolidieren musst oder irgendwie Konsolidierungsprozesse in die Wege leiten musst. Also wie schaffst du es denn, so ein Language War aufzulösen, wenn die Leute nur diskutieren? Wie kannst du denn das auflösen, wenn du in einem heterogenen Umfeld bist mit drei verschiedenen Clouds, EWS, GPC, Heroku und du musst irgendwann mal konsolidieren, weil es einfach Sinn macht finanziell, weil eben zu viel diskutiert wird, weil zu wenig Flexibilität ist, um zwischen Teams zu springen. Also wenn man langsam in die Richtung gehen will, dass man weniger Technologien hat, weil irgendwann wird es wahrscheinlich zu viel, wenn man wächst. Wie macht man denn das? Wie löse ich denn ein Language War auf deiner Meinung nach?

Andy Grunwald (00:40:56 - 00:41:09)

Wir gehen die einfache Route. Wir schmeißen alle Software-Engineers in einen Raum, machen eine demokratische Wahl und schauen uns das außerhalb durchs Fenster an und gucken, wer überlebt und die Leute sind dann das neue Team, oder?

Wolfi Gassler (00:41:09 - 00:41:18)

Und in der Zwischenzeit stellst du diese acht neuen HR-Leute an und die Recruiter an, die dir dann helfen, 70 Prozent vom Team wieder zu ersetzen, weil die haben alle gekündigt.

Andy Grunwald (00:41:19 - 00:41:22)

Hast du schon mal den Film Die Tribute von Panem gesehen?

Wolfi Gassler (00:41:22 - 00:41:23)

Bitte was?

Andy Grunwald (00:41:23 - 00:41:53)

Die Tribute von Panem mit Jennifer Lawrence. Der Film dreht sich um verschiedene Distrikte, wo Menschen leben und wie reich oder arm diese Distrikte sind unterscheidet sich halt. Und dann wird pro Intervall, einmal im Jahr oder so, ein oder zwei Leute aus einem Distrikt gewählt und einfach in so eine Art virtuellen Dschungel reingepackt. Und das wird alles übertragen. Und in dieser virtuellen Dschungel müssen die dann ums Überleben kämpfen. Und ab und zu spawnen dann mal so Überlebenspakete oder Waffen und so weiter und die müssen sich dann töten.

Wolfi Gassler (00:41:53 - 00:41:57)

Das ist so eigentlich... Also Dschungelcamp ungefähr.

Andy Grunwald (00:41:57 - 00:42:45)

Ja, so ungefähr wie Dschungelcamp und Big Brother, halt nur ein bisschen Action und so weiter und so fort. Und so ähnlich stelle ich mir diese Language Wars vor. So nach dem Motto, irgendwie so die Distribute von Panem. Du hast halt diese Strikte, die sind halt die verschiedenen Sprachen, und die packst du dann alle in den Raum. Und ich sag jetzt nicht, du solltest da irgendwelche Waffen reingeben oder so, weil ... könnte könnte leute zu zu schaden kommen aber irgendwie kann man das halt schon so so so sehen ja weil am ende bin ich mir gar nicht sicher ob da wirklich gewinner rauskommen können denn jetzt mal angenommen du bist jetzt für java und ich bin jetzt für gold hast du jemand dritten für für javascript oder haskell oder sowas ist ja egal Und jetzt mal angenommen, du gewinnst nach fünf Tagen Diskussion, fühlst du dich wirklich als Gewinner oder denkst du dir, boah die fünf Tage waren jetzt schon echt anstrengend und ich brauche jetzt erstmal echt Urlaub?

Wolfi Gassler (00:42:45 - 00:42:46)

Natürlich fühle ich mich als Gewinner.

Andy Grunwald (00:42:46 - 00:43:27)

Mach meine Pointe nicht kaputt. Nein, wie macht man das? Also das ist natürlich der ganz falsche Weg meines Erachtens nach. Ich bin mir auch nicht sicher, ob ein demokratisches Wahlverfahren dort wirklich sinnvoll ist. Ich glaube, im Allgemeinen sollte man sich wirklich, wirklich, wirklich wichtige Gedanken darüber machen, wie man eine Art Konsolidierung macht und wie man das angeht. Also wirklich einen Prozess definieren und niederschreiben. Wer hat das finale Sagen? Wer ist wirklich der sogenannte Tiebreaker, wenn es aus irgendeiner Art und Weise nicht zu einer Entscheidung kommen kann? Wer hat ein Vetorecht? Wer kann's overrulen? Wer entscheidet das eigentlich?

Wolfi Gassler (00:43:27 - 00:44:37)

Also eigentlich eh wie man in Teams das Ganze immer anlegt, nur da ist es meistens weniger formalisiert. Ich treffe mich, ich diskutiere über irgendwas, ich schreibe vielleicht ein Design-Document, ein RFC, wie man das auch immer nennt, diskutiere das im Team und entscheide mich dann für die beste Lösung. Wenn du das aber ein paar Ebenen nach oben ziehst und viel mehr Leute involviert sind, dann wird das einfach schwieriger und dann muss man einfach jeden Teil explizit definieren in diesem Prozess wirklich wer, wann, wo, wie, warum mache ich das Ganze. Ganz, ganz wichtig, weil ich mache das als CTO ja nicht nur, damit ich endlich nur mehr eine Cloud habe, sondern ich erhoffe mir dabei was. Wahrscheinlich, dass ich mir viel Geld einsparen kann. dass man flexibler ist zwischen den Teams, dass meine Plattformteams besser arbeiten können. Also da ist ja schon ein Gewinn und den Gewinn muss ich kommunizieren, dass der allen klar ist und damit die Leute auch wissen, warum sie das Ganze machen, warum sie sich jetzt entscheiden müssen für eine Technologie oder für weniger Technologien. Und das ist halt über die schriftliche Form plus ganz, ganz viel verbale Kommunikation, glaube ich, der einzige Weg, einen sinnvollen Prozess überhaupt zu definieren.

Andy Grunwald (00:44:37 - 00:45:00)

Ein wichtiges Element ist auch, wie können Software-Engineers an dieser Entscheidung teilhaben? Weil die Software-Engineers oder die Tech-Teams sind die Teams, die die Entscheidung ausbaden müssen. Und wenn sie gar keinen Say in der Entscheidung haben, wird es, glaube ich, schwierig. Wie groß der Prozess sein muss, kommt wirklich ganz auf die Firma drauf an. Denn ein Startup mit 15 Engineers kann einen deutlich leichtgewichtigeren Prozess haben als eine Firma mit 200 Engineers.

Wolfi Gassler (00:45:01 - 00:45:05)

Hast du mal irgendwie einen großen Konsolidierungsprozess miterlebt?

Andy Grunwald (00:45:05 - 00:46:44)

Ja, ich war sogar daran beteiligt. Und zwar haben wir damals bei Trivago die Cloud-Infrastruktur konsolidiert. Und zwar war Trivago ganz lange eine Firma, wo der Alles-geht-Ansatz gewählt wurde. Und das hat sogar bis auf die Infrastruktur runtergebubbelt. Wir hatten Amazon, wir hatten GCP, wir hatten Heroku, wir hatten Digital Ocean, wir hatten Microsoft Azure. Also wir hatten echt verschiedene Cloud-Provider im Einsatz. Manche mit mehr Spend, manche mit weniger. Also der meiste Spend war damals auf Amazon und auf Google. Und dann ein paar Applikationen auf Heroku und ein paar auf Digital Ocean. Dann vielleicht zu den Active Directory auf Azure und so weiter und so fort. Und als es dann genau zu dem Punkt kam, den ich vorhin erwähnt hatte, dass wir Service A mit Service B connecten wollen, ging es halt wirklich an Cloud-Egress-Kosten, an Netzwerktraffic. Und wie verbindest du denn Cloud A mit Cloud B und allem Drum und Dran? Und da fing es dann langsam echt an, schwierig zu werden, weil wir auch Leute zwischen Teams gewechselt haben und das dann wirklich, ah, wie läuft denn das Access-Management-Konzept auf Amazon, wie läuft das Access-Management auf GCP? Alles schwierig, ja. Auf jeden Fall haben wir dann ein großes Projekt gestartet, eine Entscheidung zu treffen, okay, auf welche Cloud gehen wir jetzt und auf welche Cloud vereinheitlichen wir alles. Und da ging es genau darum, okay, wir haben einen Prozess definiert. Retrospektiv betrachtet würde ich sagen, wir hätten den besser kommunizieren können am Anfang, muss ich zugeben. aber wir haben eine working group gebildet und diese working group hat dann sich die die kosten angesehen natürlich versucht hat hochzurechnen ja weil du musst ja natürlich schon das datenvolumen aus allen clouds angucken und so weiter.

Wolfi Gassler (00:46:44 - 00:46:51)

Und in dieser working group waren leute von von beiden lagern oder von allen lagern drinnen also AWS, GCP, Heroku.

Andy Grunwald (00:46:52 - 00:47:10)

Ja, nicht von jedem Lager, so Heroku, weil da liefen nur zwei Services oder so, das war eher sofern er liefen. Da war auf jeden Fall jeder dabei, die Verantwortlichen für die großen Plattformiers. Und da waren sehr emotionale Gespräche und das war auch nicht einfach, muss ich zugeben.

Wolfi Gassler (00:47:11 - 00:47:20)

Und wie lange hat sich der Prozess eigentlich so rausgezögert oder die Gespräche, die eigentliche Diskussion, gerade so um eine Größenordnung zu verstehen?

Andy Grunwald (00:47:20 - 00:47:48)

Irgendwas so zwischen anderthalb und zwei Monaten, glaube ich. Ging natürlich auch um ab und zu mal Wartezeiten. Wir hatten dann professionelle Consultants von Amazon und von Google auch dabei, die uns dann bei der Kostenschätzung geholfen haben und so. Also um wirklich eine fundierte Datenbasis zu haben. Es hing natürlich dann ja auch an den Kosten, aber auch an der Firmenstrategie. Wie sieht es in drei Jahren, fünf Jahren aus? Solchen Input haben wir uns dann vom CTO geholt und vom Produkt. Also da zählen eine ganze Menge Informationen rein.

Wolfi Gassler (00:47:49 - 00:48:22)

Habt ihr auch bei diesem Prozess dann irgendwie definiert, was es dann bedeutet, wenn die Entscheidung getroffen ist, wie das danach weitergeht, wie da die Migration zum Beispiel funktioniert oder was das dann für die Teams bedeutet und wie damit umgegangen wird? Hat es da irgendeine Kommunikation gegeben? Ich frage so interessiert, weil ihr da wirklich nicht mehr da war und ihr aber den Schmerz erlebt von den vielen Clouds davor und von den Problemen, die das Ganze mit sich gebracht hat. hab auch gelitten unter der fehlenden entscheidung die jahre davor also hat es da dann irgendwas gegeben um die teams aufzufangen nach dieser entscheidung in irgendeiner form mitzunehmen.

Andy Grunwald (00:48:22 - 00:49:35)

Ja auf jeden fall also auch danach wurden noch sehr viel gespräche geführt um die leute aufzufangen die entscheidung noch mal zu zu kommunizieren noch mal zu erklären aber wir haben auch groß angelegten trainings Wir haben große Trainingsworkshops gemacht, wo wir Google-Professionals geholt haben. Ach so, die Entscheidung fiel dann, dass wir dann auf Google migrieren. Also, dass wir alles andere zumachen und dann alles nach Google migrieren. Wir haben die Möglichkeit angeboten, Google-Zertifikate zu erwerben, also offizielle GCP-Zertifikate. Wir haben jedem Udemy-Kurse ermöglicht und auch Bücher und auch kostenlose Playground-Accounts. Wirklich für jeden Lerntyp war was dabei. Wir haben Lernzeit in der normalen Arbeitszeit eingeplant, dass die Leute rumspielen konnten. Wir haben sogenannte Community of Practice, also Guilds, ins Leben gerufen, die sich um Knowledge Sharing kümmern. Wir haben spezielle Knowledge Sharing Sessions, also interne Sessions, angeboten und so weiter und so fort. Also da wurde eine ganze Menge gemacht. ob es dann immer wirklich wahrgenommen wurde ist eine andere baustelle ja wir haben das nicht entforst sondern eher so auf freiwilligen basis gemacht was dann vielleicht auch weiß ich nicht ob es ein fehler war oder nicht aber kommt halt ganz drauf an.

Wolfi Gassler (00:49:35 - 00:49:40)

Und haben dann alle sofort umsteigen müssen wie war das dann der big rewrite den man da danach gemacht hat.

Andy Grunwald (00:49:41 - 00:50:33)

Ah, nein, nein, auf keinen Fall. Also es war falsch, alles auf Halt zu setzen und dann alles muss neu geschrieben werden. Ich bin mir auch gar nicht sicher, ob es einen richtigen Approach gibt, aber es kam mir mal ganz darauf an, was gemacht wurde, ist, immer wenn neue Funktionalität entwickelt werden musste, wurde die dann auf dem neuen Stack gemacht und die alte Funktionalität wurde dann auf dem alten Stack erst mal gelassen, bis sie wirklich angefasst werden musste, beziehungsweise Probleme hatte und bis der Schmerz zu groß war. Weil generell sind Rewrites sehr, sehr komplex und dauern oft länger als geplant. Was aber schon gemacht wurde, es wurde ein Sunset-Date mehr oder weniger gesetzt, also wo man sagt, okay, bis zu diesem Datum gibt es dann offiziellen Support und danach sollte man schauen, dass man von der Plattform runterkommt. Im Nachhinein wurde dieses Sunset-Date dann gegebenenfalls ein paar Mal extendet. Und vielleicht nicht so konsequent durchgezogen, aber das geht ja auf mein Argument, was ich gerade gesagt habe, zurück. Rewrites sind sehr komplex und dauern auf länger.

Wolfi Gassler (00:50:33 - 00:50:58)

Hat es da eine Person gegeben, die das irgendwie im Auge hatte und die ganze Migration, die Konsolidierung dann getragen hat die nächsten Monate, also hat da irgendwer den Kopf aufgehabt und hat das organisiert und gepusht und vielleicht sich auch um die Migrationen gekümmert, die Teams gepusht hat, weil das ist ja dann der Klassiker immer die POs wollen die Features und das Team sagt ja wir müssen noch auf XY migrieren.

Andy Grunwald (00:50:58 - 00:51:22)

Also ich hoffe, dass jeder Mensch noch einen Kopf auf hat. Ich glaube, du meinst, hatte jemand den Hut auf. Aber ja, da gab es natürlich verantwortliche Personen, sowas dann politisch zu treiben mit ordentlichem Management-Sponsoring inklusive der Änderung der Product-Roadmap ist dann auch nicht immer ganz so einfach. Aber ja, natürlich, da gab es verantwortliche Leute, die dann wirklich für die Migration, für die Kostenersparnis verantwortlich waren, ja.

Wolfi Gassler (00:51:22 - 00:53:07)

Ich glaube, das ist eben auch ganz wichtig, dass da der CTO zum Beispiel oder die verantwortliche Person, aber wirklich das Top-Management voll dahinter steht und das dann auch kommuniziert und auf allen Ebenen kommuniziert, dass die POs auch genau wissen zum Beispiel, okay, wir werden in dem nächsten Jahr 30 Prozent Einbruch haben, weil wir die Technologien austauschen, weil wir eine neue Sprache verwenden, weil wir eine neue Cloud verwenden, weil wir migrieren müssen. Und damit müssen wir rechnen. Das sind 20, 30 Prozent und zwar firmenweit in allen Dev-Teams und das muss halt dementsprechend auch kommuniziert sein, weil wenn man das nur voraussetzt und dann jedes Team die eigenen POs irgendwie überzeugen muss und jedes Mal streiten muss, dass man dieses Budget bekommt für die Migration, dann kann es natürlich auch nicht funktionieren. Und umso früher ich das Ganze kommuniziere, vielleicht im Prozess schon vorab, dass wir sagen, egal in welche Richtung wir migrieren, wir werden einen Einbruch von 20 Prozent haben. Das ist gewünscht, das ist eine Management-Entscheidung und alle müssen damit leben. Das nimmt natürlich auch den Druck raus, dass die Teams dann eben genau mit diesem Argument kommen. Ja, wir müssen neue Features entwickeln, wir müssen ständig kämpfen, vor allem Teams, die vielleicht nicht so stark sind und Probleme mit ihrem PO haben. den Druck rausnehmen, möglichst früh, über einen genau definierten Prozess und die Kommunikation vom Management ist, glaube ich, schon eine ganz, ganz wichtige Sache. Und dass man eben auch spricht über die Zeit nach der Entscheidung, dass man die schon auch natürlich nicht hundertprozentig, aber möglichst genau definiert hat oder auch schon Schritte setzt, damit sich alle mitgenommen fühlen, weil das ist das größte Problem, Wenn dir dann die Leute kündigen, weil sie sich nicht mitgenommen fühlen, weil da irgendwo eine Entscheidung getroffen ist und dann nur Probleme sind durch diese Entscheidung und dann laufen dir die Leute weg. Weil das ist ja das größte Problem, was wir am Anfang auch besprochen haben. Du ziehst es möglichst schnell durch. Es gibt irgendeine Entscheidung und die kündigen plötzlich 50 Prozent der Leute.

Andy Grunwald (00:53:08 - 00:53:31)

Ja, das ist natürlich ein wichtiger Punkt, die Leute mitnehmen. Es ist aber auch ein wichtiger Punkt, deine Entscheidungen klar zu kommunizieren und auch, wie ist man zu dieser Entscheidung gekommen. Zum Beispiel, wie definiert man so ein Sunset Date? Wie sagt man, okay, ab dann und dann ist diese Plattform nicht mehr supported und die Teams sind auf sich gestellt? Bin mir gar nicht sicher, ob es so ein Richtige oder Falsch gibt, aber eine Möglichkeit ist es natürlich, mit dem größten Nutzer zu sprechen und da was auszumachen und dann schauen, was ist eigentlich realistisch, da wegzumigrieren.

Wolfi Gassler (00:53:33 - 00:53:34)

Was meinst du mit Nutzer?

Andy Grunwald (00:53:34 - 00:54:43)

Nehmen wir mal Cloud-Plattformen, so jemand ein Projekt oder ein Team, was den meisten Cloud-Spender hat oder ähnliches. Oder nehmen wir mal Microservices in Haskell geschrieben und dann der wichtigste Service oder der Service mit den meisten Lines of Code oder ähnliches. Ihr merkt schon, es ist eine schwierige Metrik, deswegen keine Ahnung, ob es da richtig oder falsch gibt, aber das ist zum Beispiel ein Ansatz. Generell kostet eine Migration natürlich Zeit, muss in den Software-Development-Lebenszyklus natürlich mit eingeplant werden. Fortschritt, wenn man den tracken kann, super, sollte man auch tracken. Vielleicht hilft sogar so eine Art Gamification-Ansatz. Also was ich zum Beispiel oft sehe, wenn man irgendwie, weiß ich nicht, man hat eine große Python-Code-Basis und man möchte die jetzt durchtypen mit MyPy oder ähnliches, dass man ganz einfach eine Excel-Liste machen kann, okay, welche Module sind denn bereits schon durchgetypt. Und dann immer und immer und immer und immer wieder, ich kann das nicht zu wenig sagen, wirklich immer und immer wieder Milestones zelebrieren. Macht eine Party. Migrationen sind nicht sexy, dennoch sollte man Erfolge feiern und man sagt, hey, cool, damit man den Leuten auch zeigt, wir bewegen uns vorwärts. Es fühlt sich zwar nicht immer so an, aber wir bewegen uns vorwärts.

Wolfi Gassler (00:54:43 - 00:55:42)

Und da auch wieder Top-Management, es ist auch echt hilfreich, wenn der CEO das mal auf irgendeiner Veranstaltung erwähnt oder so, dass das nicht eine reine technische Sache ist, dass immer nur der CTO dahinter steht, sondern auch der CEO das mal erwähnt und als großen Fortschritt sieht, weil wenn das wirklich 20% der gesamten Zeit einnimmt, dann ist das ja schon ein Riesenprojekt. Also was gibt es sonst für Riesenprojekte, die 20% der gesamten Dev-Ressourcen einnehmen? Also auch da wieder vollen Support von oben und umso mehr das zelebriert wird, umso besser. Und da fühlen sich die Leute dann halt auch vielleicht mitgenommen, vor allem die, die vielleicht auf der anderen Seite waren, die verloren haben, wenn man es so nennen will. Und dann halt aber vielleicht doch dabei bleiben. Die Vorteile sehen, mitwirken und dann halt auch dieses Lob bekommen von allen Seiten. Und das ist, glaube ich, die einzige Möglichkeit, wie man die Leute eben noch mitnehmen kann und halten kann. Unter der Voraussetzung, man hat halt Leute, die möglichst flexibel sind und eben nicht nur auf eine Technologie gepinnt sind.

Andy Grunwald (00:55:42 - 00:56:50)

Genau für diese Leute, die auf eine Technologie gepinnt sind, für die wird es natürlich schwierig. Also der Effekt auf die Mitarbeiter, Wolfgang hat das gerade schon erwähnt, kann schon heftig sein. Leute haben halt Vorlieben. Sie haben ihre Karriere darüber ausgelegt, zum Beispiel im Cloud-Business-Bereich. Ich bin Experte in AWS oder GCP und habe da ihre zertifikate gemacht oder ja war experte und kennt sich wirklich dann in den ganz tiefen klassen aus und so weiter und das ist auch völlig okay wenn man seine karriere darum aufbauen möchte doch man muss sich bewusst werden das ziel ist nicht und das ist auch nicht möglich alle happy zu machen ja ich sage immer die arbeit ist kein wunschkonzert wir sind hier im ponyhof Man kann aber auch sagen, in der Regel verlassen die Leute eine Firma, vielleicht nicht unbedingt immer wegen der finalen Entscheidung, sondern eher wegen anderen Gründen. Und die Entscheidung ist nur irgendwie die Kirsche auf meinem Spaghetti-Eis. Merkste was, ne? Auf Spaghetti-Eis gibt's nämlich keine Kirsche. Sondern eher, wenn die Leute kein Mitspracherecht haben, wenn die Leute nicht wissen, wie sie einen Effekt auf die Entscheidung hatten. Oder wenn die Argumentationsgrundlage einfach schwierig bis nicht existent ist.

Wolfi Gassler (00:56:50 - 00:57:12)

Ist Spaghetti-Eis eigentlich eine NRW-Sache? Ich habe das davor nicht gekannt und habe das erst in Düsseldorf kennengelernt. Also vielleicht alle, die uns zuhören, vielleicht schreibt uns mal, ob Spaghetti-Eis bei euch ein Ding ist, weil in Düsseldorf gibt es das irgendwie groß an jeder Ecke. Aber gut, die Vergleiche sind dann immer schwierig mit Spaghetti-Eis, wenn es um Personen geht.

Andy Grunwald (00:57:12 - 00:57:29)

Ihr merkt schon, der Wolfgang ist wieder auf seinem Happy Pass. Also generell ist es halt bei den Effekt auf die Mitarbeiter recht wichtig klare Prozesse zu haben, um Technologien zu konsolidieren oder klare Prozesse, um auch neue Technologien einzuführen, falls ihr eine Konsolidierung anstrebt.

Wolfi Gassler (00:57:30 - 00:59:13)

Aber man muss natürlich sagen, man verliert wahrscheinlich MitarbeiterInnen. Das ist ganz klar und ein paar werden abspringen, so wie es halt immer ist. Manche sind mit der Entscheidung nicht einverstanden, manche sind halt einfach solche Spezialisten und das ist ganz klar, wenn ich der absolute Pro bin im Netzwerk-Stack und mich da zu Hause fühle und gerne irgendwelche Switches, Router konfiguriere und bin zu Hause im Datacenter, schlafe da zwischen meinen Racks und dann steigt plötzlich die Firma auf Cloud um, dann will ich vielleicht einfach nicht mitmachen. Es ist vollkommen legitim. Und ich glaube, das ist, wenn man dann so erwachsen ist und das auch dementsprechend kommuniziert und sagt, okay, du bist Spezialist in diesem Bereich oder wenn sich jemand, keine Ahnung, in irgendeiner Sprache weiterbewegt, BHB Core Contributor ist und nur BHB programmieren will, klar, wenn dann BHB abgelöst wird, ist es schwierig, da weiterzumachen, wenn diejenige Person einfach sich weiter im BHB entwickeln will. Vollkommen in Ordnung. Und dann trennt man sich halt, schließt dieses Kapitel ab. Mit dem muss man leben. Also 100 Prozent der Leute mitzunehmen bei Konsolidierung, bei einer großen Konsolidierung zumindest, ist schwierig. Aber umso mehr man kommuniziert, umso besser man die Personen einbindet, umso mehr Möglichkeiten man bietet, umso eher kann man die Leute mitnehmen. Und ich glaube, eben da muss man vielleicht beim Hiring auch schon ein bisschen Auge darauf werfen, wie flexibel sind Leute, wie sehr sind Leute auf eine Technologie gepinnt, wie ist meine Firma aufgestellt, in welche Richtung will ich mich entwickeln. Also da vergisst man oft beim Recruiting drauf zu schauen und wenn man da aber schon ein bisschen die Flexibilität mitnimmt, dann hat man vielleicht drei Jahre später einfach wesentlich leichteres Leben, wenn man dann mal konsolidiert.

Andy Grunwald (00:59:13 - 00:59:41)

Ich glaube generell kann man sagen, jede Änderung in der Firma kann einen positiven und negativen Effekt auf die Mitarbeiter haben. Was mir zumindest immer hilft ist, am Ende hat das C-Level Management, die Geschäftsführung, den Hut auf. Und diese Menschen sind dafür verantwortlich, dass du einen Job hast und Gehalt kriegst. Du musst nicht immer jede Entscheidung geil finden, die die machen, aber sie tragen die Verantwortung, dass du deinen Job in der Regel behältst. Klar, jetzt bei den Layoffs ist das jetzt vielleicht nicht so wahr.

Wolfi Gassler (00:59:42 - 00:59:45)

Wenn wir trotzdem verantwortlich dafür verantwortlich aber.

Andy Grunwald (00:59:45 - 01:01:30)

Ob sie dann die verantwortung immer tragen ist dann immer so eine andere geschichte aber wenn wir das jetzt einfach mal auf die konsolidierung beziehen ist es natürlich so dass sie das nicht machen weil die gerade langweilig ist oder hoffentlich nicht dass deren dass sie sich ihren job rechtfertigen wollen hey wir machen eine konsolidierung die migration große tech migration deswegen ist der cdu benötigt ich hoffe das ist jetzt nicht der fall. Jetzt ist aber die große Frage, wenn ihr nicht wirklich wisst, in welchem Stadium eure Firma gerade ist und ihr fragt euch, hey Moment, steht eine Konsolidierung an oder nicht? Ich finde es immer ganz hilfreich, sich zu fragen, warum ist man überhaupt in der einen Situation, in dem Alles-was-geht-Ansatz oder in der anderen Situation, der einen Technologieansatz und was kann dazu führen? Ich bin immer ein sehr, sehr großer Freund von Kontext, so nach dem Motto zu verstehen, wie sind wir in die eine Situation geschlittert oder wie sind wir in die andere Situation geschlittert. Und besonders so Sachen wie die Umgebung, die Leute und die Geschichte spielt da eine große Rolle. Die Geschichte zum Beispiel, ist das ein altes Unternehmen, wo IT ein Cost-Center war und es entwickelt sich gerade zur Digitalisierung, wo die IT ein Innovationstreiber ist, würde ich mal sagen. Klassisches Beispiel ist so die Autoindustrie, Volkswagen. Oder ist das einfach ein hart neues Startup, was gerade frisches Funding hat und jetzt sehr sehr schnell das Produkt evaluieren muss. Oder die Umgebung. Woher kommt das Unternehmen? Und hat das Unternehmen vielleicht viele Subunternehmen gekauft, also Akquisitionen? Das bedeutet, du kaufst ja in der Regel einen Tech-Stack, der muss weiterbetrieben werden. Dann holst du dir automatisch einen nicht-ein-Technologie-Ansatz ins Haus. Das ist vielleicht dann so ein Hybrid. Aber ich glaube, wenn man den Kontext versteht, woher kommen die Leute, wie bin ich da reingeschledert, dann ist es vielleicht eine Möglichkeit, die Konsolidierung oder halt auch Nicht-Konsolidierung besser zu verstehen.

Wolfi Gassler (01:01:31 - 01:01:40)

Und was ist jetzt für dich der Idealweg? Also die zwei Extreme sind es beide natürlich nicht, aber was ist jetzt der Idealweg dazwischen? Wo liegt der?

Andy Grunwald (01:01:40 - 01:03:02)

Als junger Software-Ingenieur hätte ich gesagt, der Alles-Kann-Nix-Muss-Weg, so nach dem Motto, wo ich wirklich komplette Freiheit habe, weil es mir persönlich sehr viel Spaß gemacht hat, retrospektiv betrachtet, finde ich, ist das die falsche Art und Weise. Ich denke, der heilige Graal ist, ein getrimmter stack und getrimmter stack meine ich jetzt nicht in vollkommenen hybriden sondern eher sowas wie ein ein technologie ansatz aber mit einem bisschen spielraum so was meine ich damit ich meine damit zum beispiel die firma definiert einige core sprachen oder core technologien die von dem plattform team oder von irgendwem supported werden da wo man sagt okay In der kompletten Firma sind unsere Coresprachen C++, Python und irgendwas anderes. Und dass man darauf dann den Support wirklich umbaut. Das ermöglicht sehr viele Innovationen, rechts und links, das schränkt nicht so sehr ein. Und dass man dann einen recht guten Prozess hat, wie man eine neue Technologie vorschlägt. Und besonders bei dem neuen Vorschlag, und so ist das in der neuen Firma, in der ich arbeite, Das Warum wird sehr, sehr hart gechallengt dahinter, was ich super finde. Also warum brauchen wir eine neue Sprache? Welches Problem wird dadurch gelöst? Und wenn man das klar hat und objektiv betrachtet, dann ist das, glaube ich, schon ein guter Mittelweg. Natürlich sollte man die Verwendung von Standardtechnologien fördern, aber ich denke, experimentieren mit neuen Werkzeugen sollte man nicht verbieten.

Wolfi Gassler (01:03:03 - 01:05:09)

Und nachdem das jetzt sehr wishy-washy klingt, was du da gerade gesagt hast, Andi, weil die Bands Antworten sind immer schwierig, aber ich glaube, das sind die richtigen, aber man kann ja da auch einen sinnvollen Prozess draufsetzen. Und ein ganz klassischer ist, mit diesem Tech-Radar zu arbeiten. Da arbeiten ja relativ viele Firmen damit. Er hat ursprünglich, glaube ich, ThoughtWorks erfunden. Wir haben das bei Trivago ja auch mal eingeführt, mehr schlecht als recht, muss ich dazu sagen, weil es halt einfach schwierig, sowas einzuführen. Aber im Prinzip bildet man dann dort alle Technologien ab, die in Verwendung sind und definiert auch, in was für einem Stadium diese Technologien sind. Also ist es eine Core-Sprache, ist es eine Sprache, mit der man gerade mal experimentiert in einem Team, mal lernt, wie das funktioniert, um vielleicht eben die Sprache dann zu einer Core-Sprache zu machen. Und da gibt es, wenn ich es richtig im Kopf habe, vier Levels und die werden auch so grafisch dargestellt, wo sich die Sprache gerade befindet. in welchem Level, und eine Sprache wandert dann von ganz außen, das sind so Kreise, immer mehr in das Zentrum, wo es dann zur Core-Sprache wird. Und das ist natürlich eine visuelle Darstellung von dem ganzen Prozess, aber man muss diese Prozesse einfach definieren. Und diese Prozesse definieren dann eben, wie kommt die neue Sprache überhaupt herein? Was muss passieren, damit die eine Stufe nach oben steigt? Und wenn ich dann mal diesen Prozess definiert habe, wo auch viele Leute eingebunden sind, dann ist es natürlich auch einfacher zu konsolidieren, gar nicht zu viele Sprachen reinzulassen, aber trotzdem gleichzeitig experimentierfreudig zu sein. Wir verlinken auch gern ein, zwei Artikel zu den Techradar ansetzen, beziehungsweise Techradar ist ja nur die Visualisierung von dem Ganzen, aber die das ein bisschen genauer erklären. Und das ist sicher ein Weg, der hilft, um mal in so einen Prozess reinzukommen, damit man das Ganze definiert und besser aufsetzt. Und umso früher man das macht, umso besser natürlich. Für die Mini-Startup-Firma ist es wahrscheinlich jetzt weniger sinnvoll, aber sobald man wächst, wenn man das schon mitdenkt im Wachstum, ist es natürlich extrem hilfreich, weil wie gesagt damals, wo wir das einführen wollten bei Trivago, wo es dann darum geht, 600 Developer unter den Hut zu bringen, ist es halt einfach dann schon schwierig, das im Nachhinein einzuführen.

Andy Grunwald (01:05:09 - 01:05:39)

Aktuell bin ich halt so ein Fan von einem Unified-Stack, weil ich denke, ich bin so mehr auf der Schiene grade. Wir lösen einfach das Problem, anstatt uns jetzt mit der Technologie und runterzubeschäftigen. Aber das ist nur meine persönliche Präferenz. Aber ich hab so das Gefühl, umso älter du wirst, umso länger du in dem Job bist, desto mehr hast du den Hang, deine Failure-Cases zu kennen und einfach nur Sachen zu shippen und nicht dich konstant über bereits gelöste Probleme aufzuregen bei neuen Technologien, die ja vielleicht sogar Cutting-Edge sind.

Wolfi Gassler (01:05:39 - 01:06:36)

Ja, ich glaube, die Innovationskraft ist schon ein wichtiger Punkt. Und wenn du die irgendwie aufrechterhalten willst, dann musst du schon extrem starkes Probieren erlauben. Und nicht nur, dass deine Leute im privaten Umfeld in irgendwelchen Side Projects was ausprobieren dürfen. sondern auch in irgendeiner Form in der Firma. Da gibt es ja verschiedene Möglichkeiten von Hackathons bis zu gewissen Prozentsatz, den du in deiner Arbeitszeit für solche Sachen verwenden kannst. Also da gibt es ja Möglichkeiten und es ist halt wichtig, dass das sinnvoll definiert ist und kommuniziert ist, aber dass man auch diese Zeit in irgendeiner Form zur Verfügung stellt, weil sonst killst du meiner Meinung nach die gesamte Innovation in deiner Firma und glaube nicht, dass man das am Ende will, aber ein sinnvoller Mittelweg, der auch definiert ist in dem Prozess, um eben zwischen den zwei Extremen in irgendeiner Form, je nach Firma natürlich auch, zu fahren, ist wahrscheinlich der Idealweg meiner Meinung nach auch.

Andy Grunwald (01:06:36 - 01:06:53)

Das stimmt, da stimme ich dir zu und ist auch ein wichtiger Aspekt für Mitarbeiter-Retention, um die Leute bei der Stange zu halten, weil immer nur selber zu machen ist auch langweilig, ist auch mir langweilig, von daher, da bin ich bei dir. Da könnten wir eigentlich auch mal eine Episode machen, wie man eigentlich solche Experimente und Proof of Concepts sicher in Produktion auch testet.

Wolfi Gassler (01:06:53 - 01:06:59)

So langweilig kann die eigentlich gar nicht gewesen sein, weil mit dem Linux Rechner hast du es nicht lang ausgehalten. Oder deinem Lieblings-Mac.

Andy Grunwald (01:06:59 - 01:07:41)

Ja, es gibt Sachen, die will man, und es gibt Sachen, die möchte man einfach nicht. Und deswegen ... so. Operating-System-Fights on. Das war's auf jeden Fall von uns. Also, falls bei euch eine Konsolidierung noch mal irgendwie ansteht, definiert mal einen Prozess, kommuniziert den ordentlich. Supportet eure Leute, mit den neuen Technologien oder mit den entschiedenen Technologien klarzukommen. Versucht am besten, den großen Big-Bang-Rewrite zu vermeiden. Setzt am besten so einen Deprecation-Date, so einen Sunset-Date. und sorgt dafür, dass die Migration natürlich auch im Produktplanungszyklus irgendwie mit Platz findet. Ansonsten viel Spaß beim Milestones feiern. Ja, das ist es eigentlich in eine Nutshell, glaube ich.

Wolfi Gassler (01:07:41 - 01:07:53)

Und ich glaube, man muss sich damit anfreunden, dass Prozesse nicht immer was Schlechtes sind. Man darf das nicht verwechseln mit langsamen Prozessen, aber Prozesse definieren kann durchaus hilfreich sein, vor allem in größeren Firmen, definitiv.

Andy Grunwald (01:07:53 - 01:07:55)

Man muss da jetzt aber keine deutsche Bürokratie draufsetzen.

Wolfi Gassler (01:07:56 - 01:08:12)

Genau das soll es eben nicht sein. Wenn ihr irgendwelche Erfahrungen sharen wollt oder noch Feedback habt, schaut am besten bei uns in der Community vorbei. Link ist in den Shownotes. Und natürlich auch, wenn ihr irgendwelche wichtigen Argumente habt, warum Andy endlich mal Linux Desktop ausprobieren soll.

Andy Grunwald (01:08:12 - 01:08:17)

Wenn ihr bis hierhin gekommen seid, vielen Dank fürs Zuhören. Bis zum nächsten Episode. Tschüss. Ciao.