#96 Selbstgemacht vs. Fertigprodukt: Ein Blick auf das Not-Invented-Here-Phänomen

Nur unsere eigene Lösung ist die beste: Das "Not invented here" Syndrome (NIH)

Ihr kennt das bestimmt: Es gibt eine neue Herausforderung zu lösen. Das Team steigt sofort in die Planung ein, um die Anforderungen in Source-Code zu kippen. Ihr sitzt da und fragt euch: Das kann doch nicht sein, dass wir die einzigen sind, die dieses Problem haben. Da muss es doch schon was fertiges geben.”. Doch das Team wettert dagegen: “Unser Problem ist sehr speziell. Wir bezweifeln stark, dass es da etwas gibt, was unseren Anforderungen standhält.

So oder so ähnlich spielt es sich jede Woche in etlichen Teams ab. Es wird die eigene Arbeit über externe Lösungen gestellt. Die Nachteile werden oft später sichtbar.

Über dieses Thema sprechen wir in dieser Episode. Nicht nur, was die Gründe dafür sind, sondern auch, wie man dem etwas entgegensetzen kann.

Bonus: Warum keiner vor dem "Not invented here" Syndrome geschützt ist - Wolfgang und sein Meetup-System.

Das schnelle Feedback zur Episode:

👍 (top) 👎 (geht so)

Sprungmarken

(00:00:00) Intro

(00:00:53) Das "Not invented here" Syndrom (NIH) und Open Source

(00:09:31) Grund: Ich kann das besser

(00:15:33) Grund: Fertige Lösungen sind zu komplex

(00:26:13) Grund: Fertige Lösungen sind zu unflexible weil ein einzigartiges Problem haben

(00:40:38) Grund: Fertige Lösungen sind zu teuer

(00:48:44) Negative Effekte des "Not invented here" Syndroms (NIH)

(00:55:10) Positiven Effekte des "Not invented here" Syndroms (NIH)

(01:01:50) Wie kann man tun, um das "Not invented here" Syndrom (NIH) zu verhindern?

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:00:48)

Wir EntwicklerInnen lieben Herausforderungen. Endlich gibt es ein neues, ordentliches Problem zu lösen und wir können eine Software dafür bauen. Natürlich prüfen wir als erfahrene Entwickler zuallererst, ob es vielleicht nicht schon eine gute, fertige Lösung am Markt gibt. Wir erkennen dann aber recht schnell, unser Problem ist einzigartig. Die Standardlösung ist viel zu unflexibel und zu komplex. Und ich brauche doch nur 20% der Funktionen. Das schaffen wir im Team schneller und billiger. Also los, auf zum Coden. Ich würde gerne sagen, diese Worte kommen nicht aus meinem Mund, aber ich habe sie genau so schon gesagt. Falls ihr diese Situation auch kennt, wir sprechen in dieser Episode, warum dieses Vorgehen so gefährlich ist und wie man es auch vermeiden kann. Also los geht's, ganz ohne Coding.

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

Lieber Wolfgang, am vergangenen Abend hatte ich wieder etwas Zeit und habe unserer Engineeringkiosk.dev Webseite wieder ein bisschen Liebe geschenkt. Und zwar, wie du weißt, ist diese Webseite mit Astro gebaut. Astro ist ein JavaScript Framework zum generieren...

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

Gegen meinen Willen übrigens, möchte ich da noch einwerfen.

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

Könntest du bitte jetzt auch sagen, dass du inzwischen eigentlich auch ganz... ...es lieben gelernt hast?

Wolfi Gassler (00:01:15 - 00:01:21)

Nein, nein, also lieben gelernt habe ich es noch nicht, aber mittlerweile bin ich ganz zufrieden. Es funktioniert.

Andy Grunwald (00:01:22 - 00:02:00)

Und wie jedes JavaScript-Projekt, denn Astro ist in JavaScript geschrieben, hat auch unsere Webseite dieses Problem, dass man da gefühlt jede Woche die Dependencies updaten muss, weil sonst kann man das ganze Projekt ja in drei Wochen nicht mehr bauen. Und dann bin ich da so durchs GitHub-Repo gelaufen und dann habe ich Pull-Requests von dir gesehen. Und zwar muss ich dir ja mal danken, du organisierst ja jetzt das Meetup in Tirol. Wundervoll! Und die Meetup-Ankündigungen sind ja auch immer auf der Webseite. Doch was entdecke ich da? Ich entdecke Pull-Requests, wie du ein eigenes Anmeldesystem fürs Meetup baust. Könntest du dich bitte jetzt rechtfertigen, warum du sowas selbst baust, anstatt einer der Trillionen fertigen Lösungen nimmst?

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

Ja, weil die Lösung, die wir bisher verwendet haben, die ist jetzt kostenpflichtig geworden.

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

Was kostet diese Lösung?

Wolfi Gassler (00:02:06 - 00:02:08)

100 Dollar im Jahr.

Andy Grunwald (00:02:08 - 00:02:12)

Wie lange hast du bisher an deiner Lösung, an deiner eigenen Lösung gebaut?

Wolfi Gassler (00:02:12 - 00:02:15)

Müsste dir jetzt genau nachschauen, aber es waren sicher einige Stunden, ja.

Andy Grunwald (00:02:15 - 00:02:17)

Bist du schon live?

Wolfi Gassler (00:02:17 - 00:02:18)

Fast.

Andy Grunwald (00:02:18 - 00:02:21)

Wie viele Stunden müssen da noch circa reinfließen?

Wolfi Gassler (00:02:21 - 00:02:23)

Wenig, wenig. Es ist wirklich schon fast live.

Andy Grunwald (00:02:24 - 00:02:50)

Du möchtest mir also sagen, ich gehe davon aus, du hast davon so circa 5 bis 8 Stunden rein investiert aktuell. Realität wird mit hoher Wahrscheinlichkeit höher sein. Bei deinem Stundensatz, ich denke mal, da liegen wir so bei 100, 120, 140 Euro pro Stunde. Das bedeutet, eigentlich hättest du diesen Service locker für 5 Jahre, 6 Jahre, 7 Jahre kaufen können. Und du wärst einfach sofort live gewesen. Ist das richtig?

Wolfi Gassler (00:02:50 - 00:03:24)

Also es waren schon weniger Stunden, zu viele waren es nicht. Aber ich habe das auch aus ein paar anderen Gründen gemacht. Also einerseits auf der Feature-Seite und andererseits wollte ich so eine Anbindung mit oAuth auf Google Kalender einfach mal ausprobieren. Ist auch eine sehr schöne Lösung, muss man dazu sagen. Ich habe nicht alles selber programmiert, sondern es ist nur die Anbindung an den Google Kalender. Also eine sehr coole Lösung eigentlich. Aber ja, ich hätte das auch zahlen können und wir waren eigentlich soweit, dass wir gesagt haben, wir zahlen es. Und dadurch, ich dann aber relativ schnell diese Lösung hatte, haben wir uns entschieden, da unsere eigenen Features noch dazu zu bauen.

Andy Grunwald (00:03:25 - 00:03:34)

Also du sagst gerade, dass die fertige Lösung zu unflexibel ist, weil dein Problem zu unik ist und dass du denkst, dass du es besser kannst. Ist das richtig?

Wolfi Gassler (00:03:34 - 00:03:35)

Korrekt, ja.

Andy Grunwald (00:03:35 - 00:03:48)

Herzlich willkommen, liebe Hörerinnen und Hörer. Der Wolfgang ist vom Not-Invented-Hier-Syndrom befallen. Jetzt hast du das ganze Ding schon fast gebaut. Bist du denn überzeugt, dass das die richtige Entscheidung war? Ja. Damit hätte ich jetzt nicht gerechnet. Warum?

Wolfi Gassler (00:03:49 - 00:04:22)

Ja, wie gesagt, also die Flexibilität, weil wir können gewisse Features jetzt noch dazu bauen, die wir eigentlich unbedingt haben wollten, weil in der alten Lösung das war recht geschlossen und wir wollten eigentlich die E-Mail-Adressen da auch rausbekommen und noch eine Newsletter automatisch schicken, damit die Leute registriert werden. Und ich persönlich habe es einfach als Learning für mich gesehen, mal wirklich so eine Implementierung mit OAuth zu machen auf der Applikationsseite und mit dem rumzuspielen. Also es war Ausbildung für mich und nachdem es ein Side-Project ist und nicht so schlimm ist, wenn da was schief geht, war das für mich okay, das selber zu machen.

Andy Grunwald (00:04:22 - 00:04:25)

Ist dein Kernprodukt jetzt also eine Mieterbandmeldung und kein Podcast mehr?

Wolfi Gassler (00:04:25 - 00:04:28)

Vielleicht wird es noch zum Produkt, ja, könnte schon sein.

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

Für alle Leute, die ich noch nicht abholen konnte, und zwar das Not-Invented-Here-Syndrom, von dem der Wolfgang befallen ist, ich hoffe, der erholt sich auch irgendwann von dieser Krankheit, besagt eigentlich auf deutsch Nicht-Hier-Erfunden.

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

Und so wie jeder gute Entwickler möchte ich natürlich unbedingt abstreiten, dass ich dieses Not-Invented-Here-Syndrom habe. Also das gibt es bei mir natürlich nicht.

Andy Grunwald (00:04:51 - 00:05:11)

Ich finde das schön, wenn du etwas abstreiten möchtest, was du gerade bewiesen hast. Aber nun gut. Das Not-Invented-Here-Syndrom ist eigentlich bei einer Make-or-Buy-Entscheidung die Bevorzugung der Selbsterstellung. Das bedeutet, mein Problem ist zu unique, ich kann das besser und so weiter. Und in der Softwareentwicklung wird dieses ganze Ding eigentlich sehr, sehr, sehr negativ.

Wolfi Gassler (00:05:12 - 00:05:16)

Angesehen ich bin da auch ein großer gegner übrigens davon ich muss immer noch.

Andy Grunwald (00:05:16 - 00:05:24)

Lachen weil es gerade gemacht hat aber nur gut ich denke es gibt hier und da ein paar gute beispiele warum man das not invented hier auch hier.

Wolfi Gassler (00:05:24 - 00:05:28)

In wenden sollte ja gefühlt also mein beispiel natürlich in meinem fall ich denke.

Andy Grunwald (00:05:28 - 00:06:04)

Es hat ab und zu seine daseinsberechtigung besonders im heutigen zeitalter thema open source aber Es ist wirklich ein Thema, was man irgendwie ständig hört. Denn irgendwie redet jeder drüber, jeder moppert immer irgendwie drüber. Also ich hör's nie im positiven, sondern wirklich nur im negativen Sinne. Aber immer wenn ich weiterfrag, jeder war schon mal davon befallen. Jeder sagt schon mal, ich kann das besser, mein Problem ist so unique. Deswegen hab ich diesen kleinen Slackbot gebaut und der hostet jetzt auf Kubernetes und macht drei Slack-Nachrichten pro Tag, wo die Slack-Workflow-Engine mit hoher Wahrscheinlichkeit besser gewesen wäre.

Wolfi Gassler (00:06:04 - 00:07:04)

Also ich habe schon hin und wieder gehört, dass das positiv gesehen wird, vor allem interessanterweise in letzter Zeit relativ oft auf CEO-Seite oder CTO-Seite, die dann erklärt haben, wenn wir das damals nicht gemacht hätten vor zehn Jahren, dass wir das alles selber gemacht haben, keine Ahnung, zum Beispiel irgendeine Automatisierung mit Google Ads, um unser Marketing zu automatisieren, dann wären wir nie so weit gekommen und Das war eigentlich immer sehr positiv. Das Problem ist natürlich, wenn man das jetzt auf heute ummünzt, nur weil vor zehn Jahren das vielleicht nicht möglich war und keine sinnvolle Software am Markt war, dass jetzt alle sagen, ja, das machen die großen Firmen, die großen Firmen machen das auch ständig, alle selber entwickeln, dann machen wir das eben auch. Ich glaube, das muss man schon immer in der jeweiligen Zeit sehen und ich glaube, es wird immer weniger, dass es irgendwie keine Software für ein Problem gibt, weil einfach die Softwareentwicklung mit der ganzen SaaS-Bewegung, alles wird so schnell, es gibt überall irgendwie neue Lösungen, neue Software, neue Open-Source-Bibliotheken. Also heutzutage zu sagen, das gibt es nicht, da lehnt man sich schon sehr weit aus dem Fenster, würde ich sagen.

Andy Grunwald (00:07:04 - 00:07:21)

Und das ist auch die Killerfrage, die ich versuche immer in diese Diskussion zu bringen. Sind wir wirklich, wirklich sicher, dass dieses Problem noch nie jemand gelöst hat und noch nie jemand dafür eine Software gebaut hat? Oder sind wir einfach zu doof, um Google und Co. zu bedienen?

Wolfi Gassler (00:07:22 - 00:08:06)

Oder GitHub. Ich habe einen Kollegen, mit dem ich sehr viel zusammenarbeite und das ist eigentlich super interessant, weil jedes Mal, wenn wir irgendwie ein Problem besprechen, dann geht er als erstes auf GitHub und gibt dort mal den Suchbegriff ein und schaut, gibt es nicht irgendwo eine Open-Source-Lösung, hat das Problem nicht vielleicht schon irgendwer mal gelöst, der probiert wirklich mehrere Suchbegriffe, irgendwie Subbegriffe, um herauszufinden, gibt es nicht irgendwo was, was wir verwenden können oder vielleicht darauf aufbauen oder zumindest mal sehen, wo Probleme liegen, weil wenn sich jemand anderer da schon beschäftigt hat, 10 Stunden, dann kann man sich die 10 Stunden vielleicht sparen und kann da schon mal reinschauen in den Code. Und es ist erstaunlich, wie oft er eigentlich was findet. Ich bin jedes Mal wieder überrascht, weil ich das selber einfach nicht so in meinem Workflow integriert habe, sofort immer auf GitHub zu gehen und mal loszusuchen.

Andy Grunwald (00:08:07 - 00:08:27)

Man muss aber auch sagen, wenn man GitHub als Suche benutzt, man stolpert über sehr, sehr viele, sehr, sehr geile Projekte, aber man stolpert auch über echt viel Kram, wo man sagt, ah, weiß ich jetzt nicht, ob ich das jetzt einsetzen sollte. Aber ich find die Methode geil. Ich find die Methode wirklich ... Könnte man nicht eigentlich auch sagen, Google und dann Zeit, Doppelpunkt, GitHub.com?

Wolfi Gassler (00:08:27 - 00:08:35)

Könnte man wahrscheinlich auch, aber GitHub sucht halt schon eigentlich sehr, sehr cool im Sourcecode, in den Kommentaren, keine Ahnung, wie gut der Google eigentlich mithalten kann.

Andy Grunwald (00:08:36 - 00:08:48)

Aber, wenn ich da jetzt gegenhalten würde, schauen wir uns doch mal an, welche diese populärsten Dokumente, welche die populärsten Argumente für das Not-Invented-Hier-Syndrom sind.

Wolfi Gassler (00:08:48 - 00:08:57)

Was heißt dafür? Das ist ja kein dafür, was Leute meistens dann für Argumente aufbringen, wenn es in so einer Diskussion gibt, Make oder Buy.

Andy Grunwald (00:08:57 - 00:09:15)

Und ganz nach dem Motto vom Familienduell, wir haben 100 Leute gefragt und die Top 4 sind, ich kann das besser, fertige Lösungen sind zu komplex, fertige Lösungen sind zu unflexibel, weil mein Problem einzigartig ist und auf dem letzten Platz, fertige Lösungen sind zu teuer. Kommen dir diese Gründe bekannt vor?

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

Ich höre sie leider ständig. Inklusive, dass ich sie gerade selber vorgebracht habe. Aber ich höre sie auch ständig. Ich höre sie, wenn ich mit Kollegen und Kolleginnen diskutiere. Ich höre sie bei Kunden, bei Diskussionen. Also sie sind eigentlich ständig in meinem Ohr, muss ich ganz klar sagen.

Andy Grunwald (00:09:32 - 00:09:37)

Aber steigen wir doch mal beim ersten ein. Ich kann das besser. Ich meine, du hast ja auch gedacht, du kannst eine Meetup-Anmeldung besser.

Wolfi Gassler (00:09:37 - 00:09:53)

Also ich würde gar nicht sagen, ich kann sie besser. Also ich glaube, dass sie andere wesentlich besser können. Es war eher eine Preissache und eine Featuresache. Also ich maße mir eigentlich selten an, dass ich was besser kann als andere. Ich würde sagen, die meisten anderen Leute machen etwas besser als ich.

Andy Grunwald (00:09:53 - 00:09:56)

Aber fandst du die Lösung des Problems spannend?

Wolfi Gassler (00:09:56 - 00:10:21)

Es war keine komplexe Lösung. Also es war straightforward. Vielleicht zur Erklärung, was es geht, es geht darum, es registriert sich jemand mit seiner E-Mail-Adresse und die E-Mail-Adresse wird dann zu einem Kalender-Event automatisch hinzugefügt, that's it. Also kann man heutzutage auch mit diesen ganzen Mac.com oder N8n von der Open-Source-Variante für Automatisierungen, könnte man auch abbilden, aber teilweise ist das Clicky-Bunty komplizierter, als wenn man es dann selber programmiert.

Andy Grunwald (00:10:22 - 00:10:25)

Ich habe nicht gefragt, ob es komplex war, ich habe gefragt, ob du es spannend fandest.

Wolfi Gassler (00:10:26 - 00:10:41)

Also eigentlich ja, aber wenn man dann so mit Google bei OAuth irgendwelche Dialoge durchklickt und sich in Hilfeformen herumschlägt, um rauszufinden, warum Google da jetzt eine Validierung will und warum nicht, das macht einfach keinen Spaß.

Andy Grunwald (00:10:41 - 00:11:30)

Naja, aber oft ist das ja auch so, wenn jemand anfühlt, ich kann das besser, dass es dann auch wirklich so ein motivierendes Problem, ein spannendes Problem für Entwickler ist. Zumindest wird das oft angeführt, weil sie vielleicht auch noch nie in dieses Problem eingetaucht sind und vielleicht nicht alle Details kennen. Aber ein schönes Argument, das, was ich die Tage zur Vorbereitung diesem Podcast gelesen habe, und zwar hat jemand das Statement gemacht, dass die Masse des heutigen Software-Engineerings eigentlich nur Plumbing ist. Also du nimmst Vorhandenes und stöpselst es zusammen. Du nimmst Library A mit Library B und connectest das einfach nur, um Daten von Library A nach Library B zu nehmen. Und dann könnte man doch so argumentieren, dass wenn ich alles selber schreibe, also wenn ich das hier invente, dass das doch eigentlich richtige Software-Engineering ist, oder?

Wolfi Gassler (00:11:30 - 00:11:33)

Du meinst jetzt, dass der Glue-Code Software-Entwicklung ist?

Andy Grunwald (00:11:33 - 00:11:59)

Nee, der Glue-Code ist Plumbing. Weil ich nehme ja vorhandene Sachen, Leute haben da ihre Brainpower reingesteckt, Leute haben die harten Probleme in Libraries gekippt und ich nehme die Libraries und klebe die zusammen. Der Glue Code ist das Plumbing. Doch ich nutze ja in diesem Fall keine Libraries. Ich mach's ja selbst. Ich mach das Logging selbst, ich mach die Authentifizierung komplett selbst. Und da muss ich ja nachdenken. Das ist motivierend für mich. Und ist das nicht eigentlich richtige Software Engineering?

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

Ja, was ist schon richtige Software-Engineering? Das ist dann die große Frage, aber vielleicht das, was mehr Spaß macht unter Umständen, ja, das kann durchaus sein, als Blue-Code zu schreiben. Blue-Code zu schreiben ist selten jetzt viel Spaß, ja.

Andy Grunwald (00:12:12 - 00:12:54)

Weil ich sag mal so, die Anzahl an einzigartigen Problemen, die es noch in der Informatik, in der Softwarewelt gibt, die ist ja schon sehr reduziert. Klar, es gibt ein paar mathematische Probleme, die sehr, sehr schwierig zu lösen sind. Und wenn du die löst, wirst du reich. Aber die wirkliche ... Du hast ein Unique-Problem, weiß ich jetzt nicht, einen neuen Datenbanktreiber zu schreiben oder irgendwie so was für eine neue Datenbank, wo es dann jetzt noch keinen Treiber für gibt. Das ist ja schon etwas, was kreative und talentierte Engineers anlockt. weil immer wenn du gluck immer wenn du glucose schreibst dann also wenn ich nur noch glucose schreibe die 75 code api baue die, was in der post schreibt mit dem javascript widget das ist das das wird doch zum zum zu.

Wolfi Gassler (00:12:54 - 00:13:48)

Lange weile oder, Ihr habt das auch ganz oft schon erlebt, ganz klassisch mit dem ganzen Machine Learning und AI Trend. Da habe ich ganz oft gehört, ja, ich kann ja selber diese Open Source Library verwenden oder ein Modell bauen und kann dann schnell diese Images taggen. Das funktioniert schon. Das ist ein interessantes Problem, da kann man sich reinfuchsen, das ist super. Und wenn man es dann aber vergleicht, am Ende, nach wochenlanger Entwicklung, dann sieht man erst, okay, es ist doch nicht so leicht und die 800 Edge Cases hat man doch vergessen. Und das war dann vielleicht ein interessantes Problem. Das stimmt schon, aber die Lösung ist eine schlechtere. Und das ist halt abzuwiegen. Geht man mehr auf interessante Probleme und hat happy Leute oder stellt man vielleicht die falschen Leute ein, die nur diese harten Probleme lösen wollen? Oder hat man am Ende eine gute Lösung und bringt das Produkt nach vorne? Das ist halt immer so die Frage, in welche Richtung man gehen will.

Andy Grunwald (00:13:49 - 00:14:21)

Ich denke mir dann immer so okay, wenn du nur als Softwareingenieur von technischen Problemen getrieben bist, arbeitest du dann am Business? Also ist dein Ziel dann die Firma nach vorne zu bringen? Weil in sehr sehr sehr vielen Firmen ist es ganz realistisch so, dass du nicht kontinuierlich die harten Probleme löst. sondern dass zwar die technologie und die software vielleicht das hauptprodukt ist aber dennoch immer nur noch ein mittel zum zweck und zwar zum geld verdienen und wenn du jetzt alle immer nur harten probleme lösen selbst lösen möchtest dann hast du zwar spaß aber bringt also ist es das wirklich das richtige für das business.

Wolfi Gassler (00:14:21 - 00:15:09)

Und Ich glaube, da sind wir im Recruiting dann drinnen. Also einerseits auf der Firmenseite, aber auch die Leute, die sich bewerben. Man sollte sich halt Gedanken machen, was will man. Ich persönlich zum Beispiel habe großen Spaß, wenn ich drei APIs verbinde und am Schluss funktioniert irgendwas. Ich bin da super happy, obwohl ich nicht die einzelnen Probleme gelöst habe, aber ich habe das zusammen verbunden. Und für mich ist dann der Outcome auch super, wenn es am Ende funktioniert. Aber es gibt natürlich Leute, die an den harten Problemen ganz tief unten arbeiten wollen. Und ich glaube, das ist halt beim Recruiting muss man einfach auf den Fit da extrem achten, auf beiden Seiten. Und ich glaube, da muss man einfach die richtigen Leute haben für das jeweilige Problem, das man in der Firma hat. Und wenn man da natürlich als Firma jetzt immer die smartesten Leute haben will und nur die super Leute einstellt, dann hat man vielleicht das Problem, dass am Ende dann niemand Glue Code schreiben will.

Andy Grunwald (00:15:10 - 00:15:25)

Ich sage immer, Google hat bestimmt auch nicht immer nur Doktoren, obwohl die wahrscheinlich sehr sehr viele sehr harte Probleme haben, aber du kannst halt nicht nur Doktoren einstellen, sondern offengesprochen, du brauchst auch jemanden so wie mich, Studienabbrecher, die einfach nur das Zeug zum Fliegen bringen.

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

Wobei man auch sagen muss, die haben viele Doktoren, die Glucose schreiben und weniger interessante Projekte lösen. Also kenne ich selbst einige.

Andy Grunwald (00:15:33 - 00:15:40)

Das war das Kernargument. Ich kann das besser. Gehen wir zum zweiten. Komplexität beziehungsweise fertige Lösungen sind zu komplex.

Wolfi Gassler (00:15:41 - 00:17:04)

Ja, das ist, glaube ich, ein Problem, wo ich persönlich auch immer ein Problem damit habe, im wahrsten Sinne des Wortes. Also ich schaue mir irgendeine andere Lösung an und denke mir, boah, ist das kompliziert. Es gibt so viele Features, die Einbindung ist so kompliziert. Die machen das auch so kompliziert. Warum machen die das überhaupt so kompliziert? Was braucht man denn da alles dafür, damit man das überhaupt ans Fliegen bringt? Und die haben keine Ahnung, was für Voraussetzungen. Und das wäre doch eigentlich nur eine Funktion, die man selber schnell runterschreiben könnte. Also dieses Problem herrscht ständig. Aber das darunterliegende Problem, glaube ich, dabei ist einfach, dass man sich zu wenig mit dem Problem an sich beschäftigt hat oder mit der Lösung. Dass man eben glaubt, es ist so einfach. Aber meistens haben diese fertigen Lösungen, sei es eine Library, sei es eine API, die haben den Grund dafür. Und die haben wahrscheinlich schon zwei Jahre sich mit dem Problem beschäftigt und haben da schon recht viel Zeit investiert und sind an dem Punkt angelangt und haben schon ganz viele kleine Kinderkrankheiten behoben, die man selber gar nie am Schirm haben kann, weil man einfach sich vielleicht mal eine Stunde überlegt hat, wie die Lösung aussehen könnte. Aber jeder, der programmiert oder auch nicht nur die Programmierer, sondern alle anderen Leute wissen, dass der Teufel im Pedal sitzt und man kann das gar nicht alles antizipieren, was da auf einen zukommt. Und das ist, glaube ich, das größte Problem, dass man das nicht am Schirm hat und einfach den anderen auch nicht vertraut, dass man sofort immer nur die negativen Punkte sieht. wenn man sich eine andere lösung anschaut.

Andy Grunwald (00:17:04 - 00:18:01)

Aber ich glaube es ist auch ein unterschied wie lange man sich mit dem eigentlich problem auseinandergesetzt hat also stell dir mal vor du hast jetzt ein problem zu lösen was auf der oberfläche sehr einfach klingt und du denkst da zwei drei minuten drüber nach und auch noch zwei drei minuten das ist ja immer noch sehr einfach da frage ich mich, Was ist denn, wenn man sich da mal ein bisschen tiefer mit beschäftigt? Das bedeutet, was ist denn, wenn ich einfach mal ein Designdokument schreibe und einfach mal niederschreibe, wie würde ich dieses Problem wirklich lösen? Also dann denkt man auf der einen Seite deutlich detaillierter darüber nach. Zweitens, man schreibt die ganze Sache auf. Das bedeutet, der Kopf arbeitet noch mehr und noch mehr. Und ich sage nicht, du holst dann jede Kinderkrankheit raus. Doch ich sage, du beschäftigst dich deutlich detaillierter mit dem Problem. Und vielleicht baust du auch noch ein Prototyp in, ich sag mal, einem Tag oder so, wirklich so Timebox, um mal ein Gefühl für die Komplexität zu kriegen. Denkst du nicht auch, dass wenn man das mal niederschreibt, wie man es selbst lösen würde, dass man relativ schnell auf den Trichter kommt? Uh, das ist vielleicht doch nicht ganz so einfach.

Wolfi Gassler (00:18:02 - 00:19:37)

Wie könnte es anders sein, dass du Design-Documents vorschlägst? Design-Documents sind ja die Lösung für alles. Aber ich muss dir natürlich recht geben, umso mehr man sich mit dem Thema beschäftigt, umso besser. Und Runterschreiben ist einfach eine gute Möglichkeit, dass man sich mit den Problemen beschäftigt, weil man einfach, wenn man was hinschreibt, dann muss man das beweisen. Man kann nicht einfach sowas in die Luft behaupten. Man überlegt sich da eine Argumentationskette, macht vielleicht Research am Weg. Stimme dir vollkommen zu. Glaube aber, es ersetzt sicherlich nicht, jetzt irgendwie loszuprogrammieren. Weil erfahrungsgemäß hat man da eigentlich die größten Learnings, wenn man einfach mal damit programmiert, Hand anlegt und sich langsam vortastet. Und da ist das große Problem, wenn man sagt, okay, man beschäftigt sich mal einen Tag damit. Dann beschäftigt man sich dann einen Tag damit. Und dann sagt man, ja, eigentlich bin ich eh schon am Ende. Es ist gar nicht mehr so viel. Jetzt habe ich mich schon einen Tag beschäftigt, jetzt beschäftige ich mich ja noch am zweiten Tag. Also das ganz klassische Sunk-Cost-Fallacy, also wenn man schon Zeit investiert hat, dass man sagt, es wäre jetzt schade, das wegzuwerfen, was man schon investiert hat und dann weitermacht. Also das ist, glaube ich, auch ein großes Problem. Wenn man so konsequent ist, dass man sagt, okay, Timebox das wirklich auf einen Tag und vielleicht sogar im Team, dass ein PO sagt, nur einen Tag max und sonst auf keinen Fall, aber die Diskussion ist immer schwierig danach, dann könnte ich mir vorstellen, dass das Sinn macht. Aber das ist schon so ein Problem, Wenn man mal tiefer reingeht, dann aufzuhören, ist sehr schwierig. Bei mir selber auch. Also wenn man mal drinnen ist in einem Problem, wirklich zu sagen, ich schmeiß die fünf Tage Arbeit weg und kauf mir irgendwas, das muss man mal zusammenbringen.

Andy Grunwald (00:19:38 - 00:20:08)

Okay, du hast dann jetzt einen Tag reingesteckt, zwei Tage und du, Achtung, du hast einen Prototyp. Und jetzt am dritten Tag sagst du, ganz im Ernst, jetzt bin ich schon fast so weit, jetzt chip ich den auch. Wie oft, und das ist ja eigentlich das lustige, weil ein Prototyp ist zum Prototypen, den baust du, danach zündest du den an, weil dann weißt du, wie es geht, beziehungsweise wie es nicht geht, und dann fängst du an, das richtige Produkt zu bauen. Wie oft in deiner Karriere hast du einen Prototypen gebaut und ihn in Produktion geschippt?

Wolfi Gassler (00:20:08 - 00:20:28)

Sehr oft, und der ist dann extrem lang in Produktion geblieben. Ich bin mir jetzt auch im Nachhinein nicht sicher, ob es immer die schönste und beste Lösung war. Und vielleicht wäre die bessere Lösung trotzdem gewesen, auf irgendwas anderes zu setzen, anstatt so einen halb schwindeligen Prototypen zu bauen, der dann immer irgendwie abstürzt, den man irgendwie am Leben erhalten muss. Das braucht ja auch alles Zeit und Geld.

Andy Grunwald (00:20:29 - 00:21:13)

Ich habe ein schönes Beispiel. Und zwar, wenn du anfängst, Go zu programmieren. Ich beschäftige mich ziemlich viel mit dem Mindset hinter einer Programmiersprache. Warum ist das so? Warum das? Was ist die Designphilosophie? Und in Go ist das Minimalismus unter anderem. Besonders, wenn man jetzt von externen Libraries spricht, dann siehst du Rob Pike in den ganzen YouTube-Talks oft mal so sagen, ja, aber warum nehmt ihr denn die ganze Library? Nehmt euch doch nur die zwei, drei Funktionen, die ihr da braucht. Der kopiert sich die dann raus. ich finde das ist auch schon irgendwie so eine schöne sache weil du nutzt in irgendeiner art was fertiges aber du nutzt nicht die ganze fertige lösung weil die ganze fertige lösung mag zu komplex sein wie wie denkst du darüber.

Wolfi Gassler (00:21:13 - 00:23:36)

Also ich kann mir schon vorstellen dass das durchaus sinn macht aber da muss man halt immer abwägen, Ab wann? Ist ja so wie ein Fork im Prinzip. Also es kommt darauf an, wie weit man das natürlich maintaint, ob man nur da zwei Funktionen rauskopiert oder eben einen größeren Teil. Aber auch da bin ich der Meinung, wenn das eine Bibliothek oder eine Software oder was das auch immer ist, wenn die gepflegt wird, wenn die maintained wird, dann kann ich da natürlich schon extrem viel daraus ziehen, dass die weiterentwickelt wird, dass da Features dazukommen. Und davon kann ich dann selbst profitieren. Also so ein Klassiker ist einfach, dass sauber programmierte Libraries oder auch Tools oder Software, die sich weiterentwickeln, dann auch gerne Standardisierungen machen, also Standards einsetzen, die üblich sind in dieser Branche oder in dem jeweiligen Umfeld. Sei es jetzt irgendwelche ISO-Standards oder wenn jetzt zum Beispiel an irgendwelche Zeitbibliotheken denke. Da gibt es gewisse Standards, wie Zeiten dargestellt werden, Zeitzonen und so weiter. Wenn ich da jetzt nur einen Teil rauskopiere und dann selber irgendwie was dazu programmiere, dann habe ich wahrscheinlich nicht dieselbe Qualität wie eine Bibliothek, die sich nur auf diesen Bereich konzentriert hat, eben wie gehe ich mit Zeit um, wie mache ich diese ganzen Zeitfunktionen zum Beispiel. Also das wäre jetzt auf unterster Ebene, aber man kann das natürlich auf jeder Ebene auch bei komplexer Software spielen. Und ich glaube, da hat man einfach Vorteile, wenn man dann die Bibliothek updaten kann. Klar, wie du sagst, bei JavaScript haben wir auch eine eigene Episode dazu gemacht. Die Dependency Hell, das stimmt schon, das ist ein Problem, aber man bekommt da wirklich viele Features mit und wenn man aktiv eine Software programmiert und weiterentwickelt, dann hat man wahrscheinlich auch selber die Probleme und im Idealfall kann dann eine Library automatisch schon weiterhelfen, weil sich die eben auch weiterentwickelt und weil die die ganzen Standards implementiert. In einem Jahr vielleicht, in zwei Jahren, kriege ich dann Features einfach out of the box mit und dann denke ich mir, ja cool, das ist praktisch, das wollte ich eh schon machen oder die haben sich jetzt irgendeinen Standard reingeholt und können auch noch dieses Format explodieren, was da ganz üblich ist in der Finanzwelt zum Beispiel oder in irgendwelchen APIs oder Zeitformate. Ich kann die noch auf fünf verschiedenen Formaten explodieren. Das heißt, die Interoperabilität, die die da mitbekommen mit anderer Software, die habe ich einfach out of the box und selbst müsste die immer extra dazu programmieren. Und ich glaube, das vergisst man auch oft.

Andy Grunwald (00:23:36 - 00:23:45)

Mal ein kleiner Sidetrack. Habe ich dir eigentlich schon mal erzählt, was die schöne Theorie hinter der JavaScript Dependency Hell ist? Warum JavaScript so viele Dependencies hat?

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

Da gibt es einen Grund dafür.

Andy Grunwald (00:23:47 - 00:24:00)

Es gibt eine Theorie, die ich sehr logisch finde. Habe ich dir anscheinend nicht erzählt. Und zwar, in der Open-Source-Welt ist das Problem, dass wenn du eine Library maintainst, die sehr groß ist, dass es für dich als einziger Maintainer sehr hart ist, diese zu maintainen. Ist das richtig?

Wolfi Gassler (00:24:01 - 00:24:03)

Ja, würdet ihr mal so sagen?

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

In der Javascript-Welt haben die davon gelernt. Und zwar haben die sehr, sehr viele kleine Pakete, die einzig und allein so alleine besser zu maintainen sind. Deswegen hast du diese Javascript-Dependency Hell, weil du hast ganz viele Leute, die ganz viel kleinen Kram maintainen, dafür können die das maintainen. Versus weniger Libraries, die dann deutlich größer sind, die dann sehr schwer zu überblicken sind. Das ist so eine der Thesen, warum es in der Javascript-Welt diese Dependency Hell gibt.

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

Und wenn du die mal ... Ist nachvollziehbar, ja.

Andy Grunwald (00:24:32 - 00:25:01)

Wenn du mal so drüber nachdenkst und speziell über das Thema, was wir jetzt gerade sprechen, Komplexität, fertige Lösungen sind zu komplex. Ich find, die Dependency-Struktur von JavaScript löst das so ein bisschen. Natürlich, du hast auch andere Extreme. Du hast leftPath, eine Funktion. Das ist jetzt gegebenenfalls zu simplifiziert. Vielleicht sollten da ein paar mehr Teilen und ein bisschen mehr Value in der Library stecken. Aber generell löst doch JavaScript schon so ein bisschen dieses Komplexitätsproblem, oder? Also es bringt andere Komplexitätsprobleme hin?

Wolfi Gassler (00:25:01 - 00:26:13)

Ich wollte gerade sagen, es bringt andere große Probleme dazu natürlich, aber es ist eine gewisse Herangehensweise, die fair ist und die meiner Meinung nach auch Sinn macht, vor allem, wenn man sagt, okay, es gibt eine Library, die konzentriert sich wirklich nur auf einen speziellen Bereich, dafür macht sich super gut und die kann alle Zeitformate und egal, was ich da reinwirfe, die versteht meine Zeitformate, die kann alle Kalender und alles, was ich irgendwie brauche, kann diese Library und die verwende ich natürlich. Also das macht meiner Meinung nach durchaus Sinn und ich würde mal sagen, die Qualität im Großen und Ganzen steigt. Aber man kauft sich da natürlich dann auch immer eine Library ein, die extrem viel kann oder eine Software. Also wir nehmen ja auch zum Beispiel mit Zencaster auf, unsere Episoden und wir zahlen auch dafür. Aber wir bekommen da auch keine Ahnung was für Features mit, die wir alle nicht brauchen, die wir nicht verwenden. Und da überlegt man sich schon immer, jetzt zahlt man dafür und verwendet nur 20 Prozent, dann überlegt man sich immer, man wirft ja irgendwie 80% von dem Geld, was man da investiert, eigentlich weg. Aber ich glaube, man muss es einfach so sehen, dass man halt dafür die 20% gut gewartet, perfekt bekommt und das Problem ist damit gelöst. Und auch wenn man 80% nicht verwendet, hat man eine gute Lösung für diese 20%, die man braucht.

Andy Grunwald (00:26:14 - 00:26:49)

Um unser beiderer Zeit zu schützen. Ich werde nicht anfangen, eine Podcasting-Recording-Plattform zu bauen. Nur kurz zum Kommentar. Aber kommen wir zum dritten Punkt. Unflexibel beziehungsweise gefährdige Lösungen sind zu unflexibel, weil mein Problem natürlich einzigartig ist. Also das, was ich halt immer so gehört hab, ist, okay, der Prozess ist so hochoptimiert. Wir sind so effizient in dieser Firma. Und das Ganze ist so unik auf uns zugeschnitten. Wir haben das schon immer so gemacht. Und wenn wir das jetzt ändern würden, schwierig. Deswegen, da gibt's keine fertige Lösung für. Deswegen müssen wir das jetzt selbst schreiben.

Wolfi Gassler (00:26:50 - 00:28:33)

Ja, da ist dann auch immer die Frage, vielleicht ist man an dieser Position eigentlich nur, weil man in der Vergangenheit nie auf standardisierte Lösungen gesetzt hat. Und wie gesagt, man bekommt dann automatische Entwicklungen out of the box. Das heißt, wenn man vielleicht vor zehn Jahren schon auf eine Lösung gesetzt hätte, die sich weiterentwickelt hätte, anstatt es selbst zu programmieren, dann wäre man jetzt vielleicht auch flexibler, weil man einen standardisierten Prozess dann darauf gesetzt hätte. Aber du hast natürlich vollkommen recht, es ist immer eine schwierige Sache, ein Prozess, der sich eingebürgert hat in einer Firma, den irgendwie umzuändern, eine neue Software einzuführen, einen Prozess womöglich ändern zu müssen, weil einfach die Software das nicht kann oder nicht so anpassungsfähig ist, das ist ein Problem. Aber ich glaube, es ist auch oft eine Ausrede, auch da wieder, weil man glaubt, dass der eigene Prozess einfach so unique und einzigartig ist und optimiert ist, dass man ihn gar nicht ändern kann und soll. Und auch da glaube ich, dass man einfach teilweise zu sehr in der Vergangenheit lebt, dass man noch im Kopf hat, wir haben das vor fünf Jahren mal analysiert und haben bemerkt, okay, es gibt keine sinnvolle Software, da ist unser Prozess einfach perfekt dafür geeignet und darum bleibt es jetzt auch so. Aber fünf Jahre sind eine große Zeit und es gibt mittlerweile vielleicht Automatisierung, Jet GPD, Machine Learning, was auch immer noch dazukommt an Technologien und vielleicht sollte man das mal dann überdenken und sich nochmal hinsetzen und einfach schauen, okay, was ist der aktuelle Stand und können wir vielleicht trotzdem auf eine andere Software umsteigen, eine neue Software einsetzen, eine neue Library einsetzen, was es auch immer ist. Also vielleicht einfach eine Stufe tiefer gehen, anstatt immer zu sagen, wir haben einen unique Prozess, wir haben einen unique Ablauf in unserer Software und wir können nichts anderes verwenden.

Andy Grunwald (00:28:33 - 00:28:47)

Du sagtest gerade fünf Jahre sind eine lange Zeit. Ich habe ein tolles Beispiel. Das geht über sieben Jahre und zwar SAP. Hast du schon mal irgendwo gehört, dass SAP, dass die Einführung schnell war, günstig und ein Erfolg?

Wolfi Gassler (00:28:48 - 00:28:49)

Ich glaube nur das Gegenteil.

Andy Grunwald (00:28:50 - 00:30:22)

So, und da, finde ich, kommt das Argument, unser Problem ist unique, auch ein bisschen zu tragen. Und zwar habe ich irgendwann mal einen sehr, sehr sinnvollen Satz gehört. SAP-Implementierungen sind immer teuer und schlagen immer fehl, weil man versucht, das SAP-System an deinen uniken Workflow umzubiegen. Und dann sagte irgendwann mal mehr zu mir, ich glaube der war sogar SAP-Bereiter, SAP ist unglaublich flexibel und du kannst alles anpassen und allem drum und dran, aber eine SAP-Einführung ist wirklich in der Regel nur erfolgreich, wenn du deine Workflows an SAP anpasst. Weil SAP ist eine unglaublich gute Software. Ich glaube, wir können sie alle hassen, aber den Wert kann man leider nicht abstreiten. Auf jeden Fall hat man das auch an einem schönen Projekt des Discounters Lidl in 2018 gesehen. Und zwar hat 2011 Lidl angefangen, SAP zu implementieren. 2018 haben sie das Projekt dann abgeblasen, nach sieben Jahren. Und es hat 500 Millionen Euro gekostet. Ein Projekt, wo wir eigentlich sagen sollten, too big to fail. Meines Erachtens nach Respekt vom Herrn Schwarz, solche Genitalien zu haben, um ein solch großes Projekt einfach abzublasen. Aber ich finde SAP ist immer so ein Beispiel für, sollte ich nicht vielleicht doch meinen Prozess an die Software anpassen und nicht andersrum und es vielleicht einfach nur mal testen.

Wolfi Gassler (00:30:22 - 00:32:39)

Also ich bin da ja kein großer Fan davon, also weder von SAP noch alle Prozesse irgendwie anzupassen. Bei Lidl ist ja die Frage, ist das ein gutes Beispiel für das Verhindern der Sank-Kost-Fallacy, dass ich nach acht Jahren sage, ich stoppe das Projekt? Oder war da die acht Jahre lang ständig die Sankt-Kost-Fallacy, dass man immer nach jedem Jahr gesagt hat, wir machen noch ein Jahr, wir machen noch ein Jahr und stoppen jetzt nicht? Das ist meine Frage jetzt bei dem Projekt. Aber gut, das ist auch eine andere Größenordnung, muss man auch sagen, dieses Projekt. Aber was im kleineren Rahmen jetzt bei mir so immer das klassische Problem ist, ist, dass man sagt, man will immer genau gleich weitermachen. Also es geht ja gar nicht darum, dass man alle Prozesse jetzt an SAP anpasst oder so, aber dass man sich einfach mal überlegt, okay, was habe ich denn da an Prozessen und ist der Prozess wirklich noch sinnvoll, anstatt immer zu sagen, okay, der ist schon perfekt. Den brauchen wir nicht mehr ändern und eine neue Software kann das gar nie abbilden. Und ein klassisches Problem, was man ja auch hat, ist, dass wenn man über Jahre hinweg zum Beispiel irgendwelche User Features aufgebaut hat, die noch irgendwo verwendet werden und man sich dann halt irgendwann mal auch fragen muss, sind diese Features überhaupt noch in Verwendung vom Großteil der User auf einer Webplattform, in einer App oder ist eine API noch in Verwendung von Kunden? Oder sind da vielleicht nur mehr ein, zwei Kunden drauf und ich brauche das Feature vielleicht gar nicht mehr. Ich brauche diesen Prozess gar nicht mehr. Ich kann den Prozess vereinfachen, weil wenn ich dieses Feature rausschmeiße, ist mein ganzer Prozess dann vereinfacht oder kann meine Software vereinfachen. Und da hängt man halt sehr oft an den alten Erfahrungen, würde ich mal sagen. Und da muss ich schon sagen, da ist der wirtschaftliche Zugang eigentlich der bessere, wo man einfach sagt, von wirtschaftlicher Seite, wie viele User verwenden dieses Feature noch? Was kostet dieses Feature? Ist dieses Feature ein Problem, irgendwie umzusteigen oder irgendwas anzupassen? Ist es das wert, diese zwei, drei, vier User wirklich noch zu behalten? Oder ist es vielleicht sogar wert, dass diese User vielleicht in Zukunft kündigen, wenn wir dieses Feature abstellen? Haben wir mal mit den Usern überhaupt gesprochen? Ist das vielleicht noch irgendwo automatisiert bei denen Eingebaut, dass sie das verwenden? Also da muss man schon genauer drauf schauen.

Andy Grunwald (00:32:39 - 00:33:14)

Aber da sind wir ja schon wieder bei datengetriebenen Entscheidungen. Und da stelle ich mir die Frage, wie viele Firmen sind denn wirklich so weit und haben neben ihrem Hauptprodukt denn wirklich Daten? Also es gibt ja auch Process Mining, wo man wirklich mal drauf schaut, okay, wie werden eigentlich internen Tools genutzt? Welche Features für unsere Tools nutzen wir eigentlich? Weil wenn man sowas hat, was natürlich auch enorm viel Aufwand ist, solche Daten zu erheben und du musst sie säubern und du musst sie auswerten und allem drum und dran. aber dann kann man halt schon noch in die richtung gehen reicht es nicht einfach 80 prozent des originalen problem zu lösen weil die 20 prozent eigentlich den wert ausmachen sofern man denn diese daten.

Wolfi Gassler (00:33:14 - 00:34:30)

Hat Also ich kann mich auch erinnern an eine Diskussion, die wir mal hatten, sehr große Wellen geschlagen damals. Da ist es darum gegangen, wie lange unterstützen wir gewisse Browser? Und ich bin ja natürlich, ihr habt da immer zwei Seiten, weil eigentlich bin ich ja dieser Open Source Mensch, der vielleicht auch gerne Firefox und so weiter verwendet. Aber manchmal muss man da auch ganz hart sagen, okay, das funktioniert auf Firefox nicht aus irgendeinem Grund zum Beispiel oder einem anderen Browser und dieser Browser wird von 0,5 Prozent unserer User verwendet. Macht es dann Sinn, da wirklich immer rundherum zu programmieren, extra irgendwelche speziellen Fälle einzubauen, nur damit man diese 0,5 Prozent der User unterstützt? Oder sagen wir einfach, wir verzichten auf diese 0,5 Prozent der User? Es ist teilweise eine schwere Entscheidung, aber ich glaube, die muss man einfach vielleicht auch wirtschaftlich treffen und weniger auf einer technischen Ebene. Und so eine Entscheidung wird eigentlich sehr selten diskutiert oder sinnvoll getroffen, weil, wie gesagt, wir haben diesen Fallback immer schon drinnen für diesen Browser, wir haben die User, also brauchen wir auch weiterhin diesen Fallback und wir müssen das weiterhin behandeln. Also da, glaube ich, muss man einfach ins Detail gehen und sich die Details anschauen und das ganz hart wirtschaftlich kalkulieren.

Andy Grunwald (00:34:30 - 00:35:01)

Naja gut, also klar, die wirtschaftliche Kalkulation muss gegeben sein. Vielleicht sind diese 0,5% der User auch genau die User, die dir 50% des Geldes bringen. Kann ja auch sein. Oder, in welcher Zeit bewegen wir uns denn? Also ich meine, wovon redest du gerade? Einen alten Browser zu unterstützen, vor 6 Jahren oder vor 10 Jahren, war deutlich härter mit dem JavaScript und CSS und so weiter, als heute. Heutzutage gibt es für jedes Legacy-Feature von irgendeinem Browser irgendeinen Polyfill. Das kann man sich einfach reinziehen und weiter geht's. Das ist die Diskussion.

Wolfi Gassler (00:35:01 - 00:35:36)

Ja, wobei man muss schon sagen, dass sich das jetzt eigentlich auch sehr stark in eine andere Richtung entwickelt. Und gerade ich als Firefox-User sehe das eigentlich ständig, auch zum Beispiel bei unserer Recording-Software von dem Podcast, kann die nur mit Chrome verwenden. Also Firefox wird nicht unterstützt. Auch bei anderen Videoplattformen merkt man einfach, dass Firefox weniger unterstützt wird. Und ich glaube nicht, dass das ist, weil Firefox schlechter ist, sondern weil halt einfach Firefox weniger verwendet wird, eine kleinere Userbase hat und damit einfach vernachlässigt wird. Und das merkt man schon. Also so einfach ist es nicht. Ich glaube, es gibt schon immer noch diese Probleme.

Andy Grunwald (00:35:37 - 00:35:42)

Ich würde trotzdem sehr, sehr viele Firmen challengen, die sagen, mein Problem ist unik.

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

Ich würde sogar jede von diesen Aussagen sehr challengen mit diesem Unique.

Andy Grunwald (00:35:49 - 00:35:58)

Jede weiß ich nicht wirklich, kommt immer auf den Kontext an. Ich finde zum Beispiel das interne Developer Tooling von Google. Würdest du sagen, deren Probleme sind unique?

Wolfi Gassler (00:35:58 - 00:36:46)

Ich bin mir gar nicht sicher, ob die unique sind. Die haben sicher ein Problem, was nicht viele Firmen haben von der Größenordnung. Ich glaube, der große Unterschied bei Google ist einfach, wenn die was entwickeln, entwickeln die das nicht für eine kleine Firma für zehn Leute, sondern für Zehntausende oder Hunderttausende sind es wahrscheinlich mittlerweile. Und damit habe ich eine größere Userbase und damit kann ich natürlich auch argumentieren, Wenn ich da irgendwo 0,5 Prozent einspare in meinem Prozess für meine User, dann habe ich da natürlich extrem viel gewonnen. Bei einer kleinen Firma oder auch bei einer großen Firma mit, keine Ahnung, 5.000 Leuten, da muss ich das erstmal schaffen, weil 0,5 Prozent irgendwo einzusparen bei einem Prozess von meinen Developern macht jetzt vielleicht bei 5.000 Leuten noch weniger aus, als wenn ich auf dem Scale von Google bin. Also da muss man auch ganz klar kalkulieren.

Andy Grunwald (00:36:46 - 00:37:43)

Also Disclaimer, ich habe noch nie für Google oder Facebook gearbeitet, doch das, was man im Internet auf Reddit und auf Hacker News liest, ist, alle Ex-Facebookler, alle Ex-Googler, wenn sie aus der Firma rausgehen in eine andere Firma, sie vermissen schon das interne Developer-Tooling. Weil es wird sogar gesagt, Google ist intern fünf bis zehn Jahre weiter, was das interne Developer-Tooling angeht, bei Facebook genauso, besonders die Integration in die eigene Infrastruktur. Und da könnte man schon sagen, wenn Google intern sagt, ja, fertige Lösungen sind zu unflexibel, weil ich hab ein unikes Problem, da könnte man schon sagen, hm, ja. Auf der anderen Seite müsste man fair sagen, hey, ihr habt zu einer Zeit gestartet, da war das Developer Experience noch gar nicht so ein Thema in der größeren Community, und dann habt ihr euch da in dieses unike Problem irgendwie über Zeit so ein bisschen reinentwickelt. Also könnte man auch argumentieren, seid ihr nicht selber schuld. Weiß ich nicht, aber man hört über das Tooling nur Gutes.

Wolfi Gassler (00:37:43 - 00:38:13)

Aber auch da könnte man sagen, das Kernbusiness von Google ist auch die Entwicklung von Code im weitesten Sinne, von Produkten. Wenn ich jetzt das optimieren kann, macht das vielleicht Sinn. Also bei Google sehe ich das eher als Kernbusiness als jetzt bei irgendeinem Hersteller von irgendwelchen Metallteilen, der irgendwelche Metallteile fräst oder so, dass der in die Entwicklung von seinem Tooling, also auf der Developer-Seite investiert und selber irgendwas entwickelt, zum Beispiel, für seine drei Entwickler.

Andy Grunwald (00:38:13 - 00:38:22)

Man sagt aber auch, kümmere dich um dein Kernproblem. Und das Kernproblem von Google, würde ich mal sagen, sind Mails, Ads und die Suche und nicht internes Developer-Tooling.

Wolfi Gassler (00:38:22 - 00:39:08)

Ich glaube, wenn du den Scale hast, ist das schon auch ein gewisses Kernprodukt, beziehungsweise auch da wieder. Im Endeffekt, du wirst natürlich als Hersteller von irgendwelchen gefrästen Metallteilen genauso deine Prozesse optimieren und deine Entwicklung optimieren, ganz klar. Aber die Zeit, die du investieren müsstest, um jetzt da in irgendwelche Development Tools zu investieren oder die selber entwickeln, die ist einfach extrem groß und rentiert sich dann natürlich weniger als für Google, die 100.000 EntwicklerInnen haben und dann dementsprechenden Einfluss darauf nehmen können. Also da wird es dann vielleicht so als Firma in der Firma zu einem Kernprodukt von dir, weil du hast dann die Firma, die sich nur ums Tooling kümmert in deiner Firma und das ist halt dann Firma in der Firma.

Andy Grunwald (00:39:09 - 00:39:23)

Das lustige ist, was du beschreibst, das machen ja ziemlich viele Leute. Ziemlich viele Google-Engineers und Facebook-Engineers gehen raus, gründen eine Firma und bauen dann ein internes Tool nach und verkaufen das dann an andere Firmen. Also ich meine, das ist ja ein bewährtes Business-Modell.

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

Ist ja auch ganz, ganz oft der Fall. Slack ist ja auch ursprünglich aus der Game-Industrie und ist halt daraus entstanden. Also das ist ja vollkommen okay, aber dann gründet man da quasi ein eigenes Business und dann wird es eigens vorangetrieben und dann hast du wieder das als kein Business. Aber dass jetzt ein kleines Unternehmen oder ein Mittelständler, der irgendwelche Metallteile fräst, dass der sich in allen Bereichen um alles selbst kümmert und alles selber programmiert, das muss man halt einfach kalkulieren und wenn man dann da total cost of ownership kalkuliert, ist das meistens schon eine andere Geschichte.

Andy Grunwald (00:39:57 - 00:40:24)

Und es ist natürlich mal ein tolles Gedankenexperiment. Was würde Google tun, wenn sie heute nochmal neu starten würden? Würden sie immer noch alles Google Tooling selbst schreiben oder würden sie vermehrt auf Open Source setzen? Denn auch die Zeit hat sich ja geändert von vor 20 Jahren zu jetzt. Es gibt deutlich mehr erwachsene Open Source Projekte. Es gibt deutlich einfacheren Zugang zu Open Source durch GitHub und wie sie alle heißen. Und da ist die Verfügbarkeit eine ganz andere Art.

Wolfi Gassler (00:40:24 - 00:40:38)

Man muss natürlich auch sagen, dass die meisten Open-Source-Produkte von den großen Firmen teilweise auch stammen oder ganz viele halt von den großen Projekten. Also die verwenden, würden dann sich selbst verwenden sozusagen, wenn man es von der Seite sieht, wie Kubernetes oder so.

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

Okay, jetzt sind wir kein Google, haben aber trotzdem die Entscheidung vor uns und sagen, ah, ich brauche ein Observability Stack, ich brauche Matrix Logins, ich brauche Sichtbarkeit in meiner Applikation. Da gibt es doch dieses Honeycomb. Kommt der nächste. Ah, das ist aber ziemlich teuer. Ich habe das Gefühl, die sind mir zu teuer. Das kann ich alles selbst mit einem eigenen Open Search Cluster. Wie oft hast du dieses Argument schon gehört?

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

Sehr oft und gerade kürzlich eben selbst bei unserem Anmeldesystem für das Meetup.

Andy Grunwald (00:41:08 - 00:41:11)

Deswegen habe ich es gebracht, weil ich muss das nämlich so smilen.

Wolfi Gassler (00:41:11 - 00:42:16)

Und auch da, glaube ich, ist das größte Problem, dass man die eigenen Kosten nicht ehrlich betrachtet. Das ist so das größte Problem. kann teilweise zusammenhängen, dass man einfach die Daten nicht zur Verfügung hat, weil ich glaube, die wenigsten Firmen analysieren das wirklich im Detail, was kostet mich eine Software zu betreiben, egal ob sie jetzt intern entwickelt ist oder extern, also der reine Betrieb, was habe ich für einen Aufwand damit, habe ich da wirklich jedes Problem erfasst in irgendeinem Ticketsystem, dass ich überhaupt weiß, Wie viele Probleme gibt es denn da pro Jahr mit dieser Software, mit meinem System? Wie viel Zeit geht da überhaupt drauf? Opportunity-Costs, ganz wichtig. Die Leute sind mit irgendwelchen Bug-Fixes beschäftigt und können nicht an meinem Kernprodukt arbeiten. Also habe ich diese Daten, habe ich diese Visibility? auf meine Kosten und eben auf diese Total Cost of Ownership, wie man sagt, wo alles mit reinfließt, habe ich die überhaupt? Und nur wenn ich die habe, kann ich das sinnvoll vergleichen. Und ich glaube, das ist das Grundproblem, dass man diese Grunddaten nicht hat. Und daher ist der Vergleich immer ein Unfairer.

Andy Grunwald (00:42:17 - 00:43:23)

Aber jeder Mensch, der irgendwie BWL oder Wirtschaftsinformatik oder VWL studiert hat oder vielleicht auch mal ein Buch gelesen hat, der wird dir sagen, hör mal, Opportunitätskosten, ja, die gibt es. Aber das ist auch ein bisschen so subjektiv. Weil eigentlich, ich stelle mir das immer bildlich vor. Und zwar hast du eine Abzweigung deiner Realität. Der eine Wolfgang geht rechts, baut das selber. Der zweite Wolfgang geht links, kauft sich das ein. Und später führt sich dann die Realität wieder zusammen und dann evaluiert man das. Und du kannst zwar von Opportunitätskosten sprechen. Ja, okay, ich baue das jetzt zwei Wochen selber. In der Zeit können die Engineers nicht an meinem Kernprodukt arbeiten. Aber du weißt ja nie, was für ein Value oder was für ein Outcome diese zwei Engineers in diesen zwei Wochen für dein Kernprodukt liefern würden. deswegen sind opportunitätskosten immer so eine so eine so eine es ist es ist es ist ein schönes argument aber aber ich finde es immer schwierig das ganze objektiv wirklich in in zahlen und werte zu fassen und zu sagen das ist besser als dass du kannst immer opportunitätskosten reinschmeißen du du klingst immer super klug im meeting aber es ist trotzdem sehr schwer zu materialisieren.

Wolfi Gassler (00:43:23 - 00:45:20)

Okay, dann bleiben wir mal bei den harten Fakten, würde ich mal sagen. Was man ganz oft vergisst, sind Maintenancekosten. Da gibt es meistens diese Daumenregel, 20 bis 30 Prozent hat man Kosten pro Jahr von den initialen Entwicklungskosten nur, um was sinnvoll weiterzubetreiben. Das wird ganz klassisch vergessen. Dann, was auch immer vergessen wird, wenn man darüber spricht, was kosten denn mich Leute, dass man da irgendwelche Stundensätze nimmt, die nicht realistisch sind, die nicht alle Kosten mit einberechnen. Weil gerade wenn ich jetzt ein Team erweiter, wachsen lasse, dann kann ein größeres Team nicht automatisch mehr leisten. Es gibt ja dieses bekannte Sprichwort, was ein Entwickler in einer Woche kann, schaffen zwei Entwickler in zwei. Und meiner Meinung nach trifft es zu. Und umso größer das Team ist, umso schwieriger wird es. Da gibt es Kommunikations-Overhead. In der Verwaltung gibt es Overhead. Und wer rechnet denn das mit? Es rechnet jeder dann irgendwie nur die Stunden von dieser Entwicklerin. Aber dass da ganz viel Verwaltung außenrum ist und Kommunikations-Overhead, An das denkt jetzt zum Beispiel niemand. Oder vielleicht sogar an ganz viele Software-Lizenzen, die man zusätzlich kaufen muss, nur weil ein Teammitglied mehr drinnen ist. Wird auch selten mitberechnet. Also die ganzen Kosten, die anfallen, werden meistens nicht ehrlich betrachtet, sondern nur irgendeinen Stundensatz. Und dann wird damit kalkuliert und dann sagt man, ja, das kostet 2.000 Euro pro Monat oder 5.000 Euro pro Monat. Da könnten wir ja eine Person einstellen. Aber was eine Person wirklich kostet und wie schwierig das dann das Ganze ist, ist die Frage. Und wenn ich schon eine neue Person einstelle, was könnte ich vielleicht erreichen, wenn ich diese Person auf mein Hauptprodukt setze und diese Sachen weiterentwickele, wo ich wirklich dann viel Impact habe, als wenn ich irgendwie nur in meinem Backoffice, in der Verwaltung, in irgendwelchen Nebenprozessen da irgendwo eine Optimierung raushole.

Andy Grunwald (00:45:21 - 00:46:39)

Wenn wenn wenn hätte hätte fahrradkette ja du du hast das wort so oft schon wieder genannt wie gesagt zu viel realitäten zu viel was wäre wenn, aber bei den kosten habe ich immer das gefühl das habe ich auch sehr oft in meiner karriere schon erlebt ist die sichtbarkeit der kosten und zwar, wenn du ein team intern schon hast du hast software engineers die die könnten das umsetzen, Die sind schon auf der Payroll, die kriegen schon ihr Gehalt. Dann sind das für dich implizite Kosten, weil du hast sie ja angestellt. Das sind Personalkosten, die gehen irgendwie auf das Budget der Firma. Aber wenn du jetzt eine Rechnung von einem Dienstleister bekommst, dann kriegst du ja einen Zettel Papier und da steht das dann ja wirklich drauf. Da steht dann 3000 Euro pro Monat drauf. Das sind dann explizite Kosten, die dann wohl möglich noch, wenn deine Firma Budgetierung hat, auf deine Abteilung budgetiert wird. Das bedeutet, da gehen 3.000 Euro runter, wohingegen, wenn du die Leute darauf setzt, das sind Kosten, die nicht wirklich zu deinem Budget gehören, beziehungsweise die das Budget nicht reduzieren, weil die hast du ja so oder so. Und das ist so eine Kopfsache, habe ich das Gefühl. Das explizite Kosten, da wird fünfmal mehr drauf geschaut, als implizite Kosten von Software-Engineers. Und das finde ich immer verwunderlich. Also diese Total Cost of Ownership, die du gerade beschrieben hast, die wird sehr sehr oft gar nicht so wirklich groß zusammengerechnet.

Wolfi Gassler (00:46:39 - 00:48:12)

Und was meiner Meinung nach auch noch dazu kommt, wenn wir noch mal kurz zurückspringen zu den Opportunitätskosten oder so eine Art von Opportunitätskosten, wenn ich eine externe Software zum Beispiel verwende, eine externe API, die kann ich sofort verwenden, von heute auf morgen. Da gebe ich meine Kreditkarte ein und ich kann sie sofort verwenden. Wenn ich das Ganze selber programmieren muss, dann werde ich Zeit brauchen, sogar wenn es effizienter ist. Aber ich werde die Zeit brauchen. Und da ist oft auch meine Frage, ob man nicht vielleicht auf externe Systeme setzen sollte, um gewisse Dinge auszuprobieren. Weil ganz oft hat man ja auch irgendwelche Dinge, die man mal ausprobieren will. Man weiß gar nicht, ob das wirklich Sinn macht, auch vielleicht auf der Produktseite. Man hat da sehr viel Aufwand an, um nur einen Test zu machen. Und wenn ich aber externe Library-Systeme, was es auch immer ist, mal ausprobiere, dann lerne ich das Ganze kennen. Dann kenne ich die Probleme genauer. Ich verstehe mal das Problem, bekomme da eine Erfahrung. Und dann kann ich mir immer noch überlegen, das selber zu entwickeln. Wenn ich dann merke, okay, ich traue mir das zu, das selber zu entwickeln, und es würde mir dann am Ende eben diese Rechnung ersparen, diese 5.000, die ich da jedes Monat bekomme, Dann kann man vielleicht auch besser kalkulieren und kann das angehen und hat aber sofort das ausprobiert und hat das mal getestet. Oder man kommt drauf nach zwei Wochen. Das war sowieso eine dumme Idee. Wir brauchen das Ganze nicht. Das funktioniert nicht. Unsere User nehmen das nicht an, was es auch immer ist und kann das dann einfach wieder wegwerfen und hat nur diese zwei Wochen investiert an Kosten von dieser API, von dem externen Service zum Beispiel.

Andy Grunwald (00:48:13 - 00:48:27)

Wie oft, und jetzt bitte antworte ehrlich, hast du einen Prototypen weggeworfen und nicht in Produktion geschippt? Oder anders, wie oft hättest du lieber, retrospektiv betrachtet, den Prototypen weggeschmissen und nicht in Produktion geschippt?

Wolfi Gassler (00:48:28 - 00:48:43)

Also ich habe, glaube ich, relativ viel angefangen und dann einfach gestoppt. Also das ist mir schon sehr oft passiert. Oder vielleicht einfach auf die Seite gelegt und dann war es nicht so wichtig. Oder man hat dann doch was anderes gefunden, was auch funktioniert hat. Also das ist mir wesentlich öfters passiert, würde ich sagen.

Andy Grunwald (00:48:44 - 00:50:07)

Jaja, der berühmte Proof of Concept. Wir hatten ihn alle mal einmal in den Sand gesetzt. Naja, da kommt man, glaube ich, nicht drum rum in seiner Karriere. Das waren eigentlich so die Key-Argumente. Ich kann das besser. Fertige Lösungen sind zu komplex. Fertige Lösungen sind zu unflexibel, weil mein Problem ist einzigartig. Und fertige Lösungen sind zu teuer. Das ist das, was ich zumindest immer so höre und was die 100 Leute, die wir gefragt haben, natürlich auch geantwortet haben. Aber, jetzt ist das Kind schon in den Brunnen gefallen. Was sind eigentlich die negativen Effekte von Not Invented hier? Was mir da so einfällt ist, was auch gar nicht so offensichtlich ist, aber der zunehmende Frust in der Belegschaft, wenn man alles selbst schreibt. Weil, stellt euch mal vor, ihr habt irgendwie ein, zwei Leute, die schreiben immer alles selbst. Und was wird immer vernachlässigt? Tests und Dokumentation. und jetzt müssen andere leute mit dieser software arbeiten und es gibt keine dokumentation und du musst immer diese eine person fragen mit der du vielleicht auch persönlich gar nicht so klar kommst und eigentlich versuchst zu vermeiden mit ihr zu arbeiten oder das eigene tooling hinkt hinterher gegenüber im vergleich der industrie mit den standard features. oder oder oder und dieser konstante Frust so, jetzt muss ich das schon wieder machen, da gibt es jetzt keine Dokumentation, deswegen muss ich jetzt erstmal zwei Wochen Code lesen. Ich kann mir schon vorstellen und ich habe es auch schon erlebt, dass da Frust in der Belegschaft angehäuft wird.

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

Also ich glaube ganz gut merkt man es, wenn jemand neu in das Team kommt und nach drei Wochen sagt, ich arbeite immer noch an meinem Dev-Environment-System, dass ich mal unser Produkt irgendwie ans Laufen bekomme überhaupt. weil da 100.000 Custom-Dinge sind, die man überhaupt zuerst mal verstehen muss und die Custom gebaut wurden. Das ist, glaube ich, ein klares Anzeichen, dass es irgendwo ein Problem gibt und da sollte man sich dann überlegen, ob man da irgendwas vereinfachen kann.

Andy Grunwald (00:50:33 - 00:51:09)

Aber du hast einen schönen zweiten negativen Punkt angesprochen, und zwar Onboarding neuer Leute dauert einfach länger. Stell dir das mal vor, ihr habt euch eine ganze Menge Open-Source-Software in eurem Stack. Die Chance, dass ein neuer Mitarbeiter oder eine neue Mitarbeiterin sich deutlich schneller onboarden kann, weil er oder sie vielleicht schon mal mit dem einen oder anderen Tool gearbeitet hat, könnte relativ hoch sein. Besonders zum Beispiel in einem modernen Cloud-Stack alles, was aus der CNCF kommt, Thanos, Kubernetes oder Ähnliches, Da ist die Chance vielleicht schon hoch, ah ok, ich hab mit dem einen Mann schon gearbeitet, versus ihr habt euch euren eigenen Container-Scheduler geschrieben.

Wolfi Gassler (00:51:10 - 00:52:02)

Ist übrigens auch ein großes Problem, was man oft von Ex-Googlern hört, wenn die irgendwo reinkommen, die kennen die ganzen Open-Source-Tools nicht. Also sie kommen zufällig von Google, aber sogar dann sind sie teilweise extrem unterschiedlich. Und die starten teilweise wirklich von Null, arbeiten bei einem der größten Tech-Kozerne, aber starten einfach, wenn sie in ein unter Anführungszeichen normales Unternehmen kommen, einfach wieder bei Null, weil man nie Kontakt hatte zu der klassischen Welt, würde ich es mal nennen. Und es ist eigentlich sowas ähnliches, wie wenn man alles, oder es ist dasselbe, Google macht alles selber, aber wenn du als kleine Firma auch alles selber machst, dann ist es natürlich schon ein Problem, wenn es darum geht, dann Leute zu finden, die eben wieder mit Standards arbeiten und auf standardisierte Sachen geschult sind. Darum machen Standards auch Sinn. Man entwickelt ja auch nicht alles neu und Steckdosen schauen auch immer gleich aus, Schraubenzieher schauen auch immer gleich aus. Es erfindet nicht jeder Möbelhersteller andere Schrauben.

Andy Grunwald (00:52:03 - 00:52:08)

Naja, bei den Steckdosen würde ich das schon challengen. Also wenn ich jetzt nach Amerika fliege, dann habe ich da schon andere Steckdosen.

Wolfi Gassler (00:52:08 - 00:52:23)

Ja, in unterschiedlichen Ländern ist klar, aber wie gesagt, die meisten verwenden irgendwelche Standardschrauben zum Beispiel, um was zusammenzuschrauben und entwickeln nicht ihr eigenes Werkzeug. Klar, gibt es auch manchmal, aber im Großen und Ganzen ist es schon sehr standardisiert und Standards machen durchaus Sinn.

Andy Grunwald (00:52:24 - 00:52:43)

Ein Punkt, der mich wirklich zur Weißglut bringt, und das hat so ein bisschen was mit Politik zu tun, glaube ich. Meines Erachtens nach zementiert das Not-Invented-Here-Syndrom Status und Macht, beziehungsweise es dient zu einer Art der Selbstpositionierung. Ich habe dieses Tool geschrieben, was jetzt für 5% des Revenues verantwortlich ist.

Wolfi Gassler (00:52:44 - 00:52:49)

Und alle müssen zu dir kommen, wenn sie ein Problem haben, weil selber durchblickt ist sowieso niemand.

Andy Grunwald (00:52:49 - 00:53:18)

Man macht sich also so ein bisschen unersetzbar. Und wenn man das sogar aktiv betreibt, schreibt man vielleicht gar nicht Dokumentation, weil alle Leute sollen zu dir kommen. Die sollen dich fragen. Das Management soll sehen, wie wichtig du für die Firma bist. Und das ist natürlich auf der einen Seite der größte Scheiß und Schwachsinn den ich je gehört habe, denn meines Erachtens nach ist, mach dich umso ersetzbarer wie möglich, dann bist du der wertvollste Mitarbeiter, weil du einfach der Multiplikator bist und.

Wolfi Gassler (00:53:18 - 00:53:19)

Du kannst in den Urlaub.

Andy Grunwald (00:53:20 - 00:53:46)

Das auch, klar. Und ich find's einfach unglaublich schrecklich. Denn du bist angestellt, um den Traum von jemand anders zu verwirklichen. Und deine Aufgabe ist nicht, dich wichtiger zu machen und dich selbst zu positionieren. Deine Aufgabe ist es, mehr Geld fürs Unternehmen zu schaffen. Das bedeutet, du arbeitest fürs Unternehmen und nicht für dich. Und da krieg ich die Kratzer! So. Woosa.

Wolfi Gassler (00:53:47 - 00:53:51)

So, jetzt haben wir ganz viele negative Punkte. Und ich glaube, es gibt auch nur negative Punkte.

Andy Grunwald (00:53:51 - 00:54:04)

Oder? Meines Erachtens nach bist du falsch, Wolfgang. Du bist falsch in so vielen Dingen. Du bist falsch, du hättest das Meetup-Anmelde-System nicht schreiben sollen. Bin ich immer noch fest der Meinung.

Wolfi Gassler (00:54:05 - 00:54:08)

Und du bist falsch... Ich dachte, du wolltest erst mit positiven Punkten um die Ecke kommen.

Andy Grunwald (00:54:08 - 00:55:10)

Komme ich jetzt auch. Du bist auch falsch, dass es nur negative Punkte gibt. Und zwar ist das irgendwie sehr faszinierend für mich, dass das Not-Invented-T-Syndrom, das taucht immer irgendwie nur im negativen Kontext auf. Und ich frage mich, warum? Denn ich denke, es ist nicht sofort schlecht. Ich denke, es ist ab und zu okay, wenn die Firma keine externe Lösung nimmt. Wenn die Firma oder ihr bei euch im Team mal was selbst schreibt. Meines Erachtens nach ist das Not-Invented-Tier-Syndrom wirklich nur schlecht, wenn du sagst, nur unsere eigene Software kann unsere eigenen Probleme lösen. Also wenn du dich in diesem einen Extrem befindest. Denn ab und zu denke ich, es kann auch ein Risiko sein. Stell dir mal vor, du hast ein relativ kleines Problem und da gibt es 100% ein kleines SARS von irgendeinem Bootstrapper, der hat das alleine als Side-Project gemacht. Da könnte das natürlich auch ein Firmenrisiko sein, irgendein deiner kleinen Probleme, die vielleicht auch essentiell für dich sind, aber auch dennoch klein, dich von irgendeiner Firma abhängig zu machen. Von daher, da würde ich sagen, sollten wir es vielleicht nicht selbst schreiben.

Wolfi Gassler (00:55:10 - 00:56:07)

Du hast natürlich recht, es gibt schon positive Sachen auch und es gibt auch, glaube ich, Die ganzen Punkte, die wir erwähnt haben, so dass man zum Beispiel einen sehr einzigartigen Prozess hat, das gibt es durchaus. Ich glaube, das ist ja auch okay, dass Firmen, die irgendwas Neues entwickeln, vielleicht einen sehr individuellen Prozess haben und es gibt wirklich nichts diesbezüglich. Und wenn es ja schon alles gäbe immer am Markt, dann wird es ja keine neuen Firmen, keine neuen Tools, keine neue Softwareprojekte geben, weil es gibt ja schon alles. Also ich glaube, es hat schon immer einen Grund und es kann so ein Grund auch sein. Aber ich glaube, dass in sehr vielen Fällen das kein guter Grund ist und dass es eben kein unikes Problem ist. Aber es kann natürlich in gewissen Fällen und auch bei ganz wichtigen Prozessen durchaus der Fall sein. Und sogar wenn das Problem nicht so unik ist, kann es sein, dass die Veränderung des Prozesses auch sehr schmerzvoll ist und so viele Leute irgendwie involviert sind, dass diese Veränderung einfach so teuer ist, dass sie auch keinen Sinn macht.

Andy Grunwald (00:56:07 - 00:56:08)

Was man aber sehr sehr oft im.

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

Internet liest, was du alles in diesem.

Andy Grunwald (00:56:11 - 00:56:50)

Internet liest und das auch was das Management oft als positiven Effekt angibt, beziehungsweise als Grund, warum man es selbst schreiben sollte, ist der Wettbewerbsvorteil. Oft ist dieser vielleicht nicht gegeben vielleicht der gute deutsche mittelstand denkt das immer aber hier und da mag er gegeben sein und zwar könnte man, mit zwei beispielen darüber sprechen auf der einen seite geht es um um google googles hauptbusinessmodell sind eigentlich ads würde ich mal sagen und die search engine und google mail das sind zwar immer nur a produkte, die halt dann die ganzen user anlocken aber google macht erbung mit geld.

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

Ja waren übrigens alles side project gmail zum beispiel und ich glaube google maps auch war so ein side project von irgendeiner mitarbeiter.

Andy Grunwald (00:56:58 - 00:57:53)

Was heißt das man sollte mehr meetup anmeldesysteme schreiben. Genau. Ja und Google hat auch noch eine Google Cloud Plattform, aber Google hat zum Beispiel auch eigene Prozessor Units entwickelt, also Hardware, die sind in das Hardware Business eingegangen und zwar haben die sogenannte Googles TPUs entwickelt. Spezielle Chips für Machine Learning, unter anderem auch für deren Framework TensorFlow. Und jetzt könnte man sagen, ist das wirklich ein Problem, womit sich Google beschäftigen sollte? Warum sollten sie eigene Machine-Learning-Chips herstellen? Im Endeffekt war es für die Machine-Learning-Strategie und auch mit dem Push und TensorFlow schon ein Wettbewerbsvorteil, weil sie natürlich dann die ganzen Machine-Learning-Processing-Units günstiger anbieten konnten als zum Beispiel in Amazon. Da könnte man sagen, ja, vielleicht. Ein anderer Webservervvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv.

Wolfi Gassler (00:58:03 - 00:58:08)

Er ist auf jeden Fall ein sehr großer Name in der Softwareentwicklung, ja. Hat schlaue Blogartikel geschrieben.

Andy Grunwald (00:58:08 - 00:58:59)

Auf jeden Fall hat er, glaube ich, mal für Microsoft gearbeitet. Und zwar 1980 hatte Microsoft Excel, also das Team, was Microsoft Excel geschrieben hat, einen eigenen Compiler, einen eigenen C-Compiler. Und jeder würde heutzutage sagen, what the fuck, warum haben die einen eigenen C-Compiler? Ja, damals war das so, deren C-Compiler war speziell optimiert auf den Source Code von Excel. weil da auf der einen Seite sehr gut die ganze Sache auf verschiedenen Plattformen zum Laufen gebracht hat. Also auf der einen Seite den Macintosh und auf der anderen Seite Intel-PCs. Und die Binary, die da rauskam, war halb so groß. Da sagt man, wieso spielt die Binary-Größe heute noch eine Rolle? Ja, 1980 gab es leider nicht so viel RAM. Und 1980 gab es auch noch die sogenannten Floppy Disks. Da hat die Größe der Binary schon eine Rolle gespielt. Besonders, wenn wir über 20 Floppy Disks oder 10 Floppy Disks sprechen.

Wolfi Gassler (00:58:59 - 00:59:44)

Ja, manchmal würde man sich wünschen, dass es noch mehr eine Rolle spielt, wenn man so manche Software aktuell ansieht. Aber genau das ist das Problem. Die Beispiele, die du jetzt bringst, die werden dann immer als Argument verwendet. Und was haben wir da für Beispiele? Microsoft mit Excel ist jetzt keine kleine Firma. Google mit Google Cloud ist jetzt auch keine kleine Firma und ich würde mal sogar sagen, deren Hauptbusiness für die Cloud-Unit ist eben die Cloud und vielleicht Prozessoren auch, wenn man auf dem Scale ist. Und jetzt kommen dann irgendwelche Mittelständler oder noch kleinere Firmen oder Einzelpersonen in dem Team und sagen, Google hat es ja auch so gemacht und Microsoft hat es auch so gemacht. Jetzt müssen wir das ja auch so machen. Wir müssen unsere eigenen Sachen entwickeln, weil das so wichtig ist. Also ich glaube, das sind immer die Argumente, die da aufgebracht werden.

Andy Grunwald (00:59:44 - 00:59:52)

Du kommst mir jetzt hier mit dem Argument, das sind ja alles große Firmen. Ich habe Google gefragt, wie viele Mitarbeiter hatte Microsoft 1980? Was denkst du?

Wolfi Gassler (00:59:52 - 00:59:55)

Keine Ahnung, aber mehr als 100.

Andy Grunwald (00:59:55 - 01:00:03)

1985, also fünf Jahre später, nach meiner Story, hatte die Firma 900 Mitarbeiter. Also, das ist nicht das Microsoft von heute, worüber ich spreche.

Wolfi Gassler (01:00:03 - 01:00:07)

Ja, aber es war auch eine andere Zeit. Damals gab es auch nicht so viel am Markt.

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

Das ist korrekt.

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

Also man muss schon immer aufpassen, was man da für Geschichten an Land zieht, weil, wie gesagt, entweder sind es ganz andere Firmen oder irgendwas aus der Vergangenheit, sind für mich keine guten Argumente eigentlich.

Andy Grunwald (01:00:20 - 01:00:26)

Weiß ich jetzt nicht. Deine Argumente mit deinem Mieter-Warnmeldesystem haben mich jetzt auch nicht überzeugt. Du hattest es trotzdem gemacht, weil du Spaß hattest.

Wolfi Gassler (01:00:26 - 01:01:07)

Genau. Und das ist, glaube ich, ein großer, positiver Vorteil, wenn man dann Spaß dran hat oder vielleicht auch was lernen kann. Für mich war da eben auch viel Learning dabei, dass ich mich mal auseinandersetze mit diesen Libraries und das ausprobiere. Das war schon lange auf meiner To-Do-Liste. Da macht das natürlich auch Sinn. Und ich glaube, auch wenn man in einem gewissen Umfeld, in der Firma, was selber entwickelt, kann das sehr wohl dazu beitragen, dass man was lernt. Aber man darf es halt dann nicht als gottgegeben sehen, dass man das immer macht und einfach, dass das immer in der Firma so ist und dann alles nur mehr selber macht. Aber dann muss es halt wirklich als Learning gekennzeichnet sein auch. Und wenn dann, wie bei Gmail, ein großes Produkt daraus entsteht, ist es auch nett, aber es war geplant als Nebenprodukt.

Andy Grunwald (01:01:08 - 01:01:29)

Das sind jetzt diese One-Shot-Stories wie Dropbox als Start-Up und so weiter. Also mal ganz offen gesprochen, wie viele Start-Ups werden gegründet und wie viele Start-Up kennst du, die dann irgendwie einen großen Status erreichen. Wenn du mir jetzt ankommst, ja, ich mache jetzt hier das Side-Projekt, weil das könnte das nächste Google-Mail werden, dann sage ich auch, weiß ich jetzt nicht, ob das Argument wirklich zieht.

Wolfi Gassler (01:01:29 - 01:01:50)

Ja, richtig, aber das war ja mein Punkt. Also das Argument ist ja nicht, ich will was bauen, was dann ein Produkt draus werden kann, sondern ich baue was, um irgendwas zu lernen und wenn das ein Produkt wird oder wenn sich das so weiterentwickelt, ist ja gut, aber ich kann nicht mit diesem Argument reingehen, ich könnte ja auch ein Produkt draus bauen und so weiter. Das kann ein nettes Nebenprodukt sein, aber es sollte kein Argument dafür sein.

Andy Grunwald (01:01:51 - 01:01:58)

So, aber oft ist man ja bereits in einer Firma oder in einem Team gefangen, wo dieses Syndrom bereits vertreten ist.

Wolfi Gassler (01:01:58 - 01:02:00)

Zeig mir ein Team, wo es das nicht gibt.

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

Ja, siehst du, also gebittert schon. Dann frage ich mich aber trotzdem, okay, wie kann denn die nächste Entscheidung besser getroffen werden? und ich fand die story sehr schön die du erzählt hast story dass dein kollege erstmal auf github geht und sich fragt dieses problem hat doch bestimmt schon mal gelöst das fand ich fand ich sehr schön eine erfahrung die ich in meiner karriere machen durfte ist folgende und zwar haben wir mal einen Case durchgerechnet, ob wir alle On-Premise-Data-Center schließen sollen und die ganze Infrastruktur in die Cloud bewegen sollen. Da geht es natürlich knallhart um Kosten. Da könnte es gegebenenfalls auch um Politik gehen. Und zwar gehe ich mal stark davon aus, dass das Team, was die On-Premise-Data-Center betreibt, ein Interesse daran hat, die On-Premise-Data-Center weiter zu betreiben. Und da gibt es ja wahrscheinlich noch andere leute die die cloud lieber nutzen wollen was da in dieser evolution sehr geholfen hat ist wen fachfremdes beziehungsweise ein außenseiter mit ihnen die entscheidung einzubeziehen.

Wolfi Gassler (01:03:02 - 01:03:03)

Eine eine consultant meinst du.

Andy Grunwald (01:03:04 - 01:04:05)

Nee, kann ja auch. Wir haben damals jemanden intern aus der Firma mit reingenommen, der keinen persönlichen Benefit von der On-Premise-Entscheidung oder der Cloud-Entscheidung hatte. Und diese Person hat sehr, sehr viel Objektivität in die Runde gebracht, weil diese Person hat halt einfach jedes subjektive Argument einfach mal in die Luft zerrissen. War natürlich dann nicht immer schön die Diskussion. Im Endeffekt könnte man sagen, dass diese Person aber sehr, sehr viel Gleichgewicht reingebracht hat. Jetzt mal unabhängig von der finalen Entscheidung, aber es wurde objektiver darüber gesprochen. Und wie gesagt, das muss jetzt kein Konsultant sein, weil es ist immer, Konsultant finde ich immer wie so ein Gutachter. Ja, ich möchte ein Auto verkaufen. Ich beauftrage einen Gutachter, um das Auto zu schätzen. Natürlich wird das Auto ein bisschen teurer, als wenn du als Käufer einen Gutachter beauftragt, um das Auto zu schätzen. Also da könnte auch der Consultant sein. Wer hat den Consultant beauftragt? Jemanden aber, der in der Firma sowieso schon arbeitet? Das ist eine andere Grundvoraussetzung.

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

Also ich würde sagen, umso externer, umso besser. Klar kann man da natürlich auch in der Auswahl ein bisschen schummeln und den richtigen auswählen. Aber ich glaube, umso weiter weg, umso besser. Und externe Leute sind allgemein weniger attached zu irgendwem. Auch in der Politik von der Firma natürlich sind die nicht involviert. Und da sind glaube ich Consultants oder solche Sparing-Partner, würde ich sie einfach mal nennen, vielleicht auch von befreundeten Firmen, wenn man da irgendwie in Kontakt hat. Also da gibt es schon viele Möglichkeiten, aber eine sehr gute Möglichkeit, die man eigentlich immer hat, sind meiner Meinung nach neue MitarbeiterInnen, irgendwelche Juniors, vielleicht studentische Hilfskräfte, Studierende, die irgendwo mit dabei sind, weil die haben diesen frischen Blick. Die haben vielleicht auch, wenn sie jetzt von der Uni sind, irgendwie ein paar neue Dinge gehört, dass man die einfach mal anhört und wirklich aktiv befragt. Also das ist immer mein Tipp Nummer eins. Auf diese Leute, die noch keine Scheuklappen haben, die mit frischem Wind reinkommen in den ersten Wochen, einfach zuhört und das genauer mitnimmt, dieses Feedback, weil diese Leute haben sehr oft Recht. Und die sagen das im Idealfall einfach mal, weil sie das nicht besser wissen. Die haben keine Monate Politik hinter sich, Monate irgendwelche Diskussionen in der Firma, warum was wie gemacht wird, sondern die schlagen einfach mal irgendwas vor. Und auf die sollte man, glaube ich, viel, viel mehr hören. Und man kann denen ja auch erklären, warum man irgendwas eben nicht so macht, weil da muss man sich ja auch selber damit beschäftigen, wenn man diese Argumente bringt, aber man beschäftigt sich damit und wenn man da ein bisschen offen an diese Sache rangeht, dann kann man von diesen Personen extrem viel lernen.

Andy Grunwald (01:05:47 - 01:05:53)

Kennst du eigentlich den berühmtesten Hacker-News-Kommentar? Der, der schon hunderttausendmal gequotet wurde?

Wolfi Gassler (01:05:53 - 01:05:58)

Ich glaube, du hast ihn schon mal erwähnt, sogar in einer Episode, wenn mich nicht alles täuscht, aber ich habe es ehrlich gesagt auch wieder vergessen.

Andy Grunwald (01:05:59 - 01:07:23)

Wenn ich über das Not-Invented-Here-Syndrom spreche, dann erinnere ich mich irgendwie daran. Denn vielleicht ist es auch irgendwie so die Art, wer in den Entscheidungen involviert ist und wie dann dieses Not-Invented-Here-Syndrom getrieben wird. Denn Dropbox Kennt, glaube ich, heutzutage jeder, ein File-Sharing-Dienst, der es sehr einfach macht, Dateien über Devices zu teilen, hat 2007, im April 2007, auf Hacker News gelauncht. Der erste Kommentar, das ist der bekannteste Kommentar auf Hacker News, sagt, For a Linux user, you can already build such a system yourself quite trivially by getting an FTP account, mounting it locally with curl FTP-PS, And then using SVN or CVS on the mounted file system. From a Windows or Mac, this FTP account could be accessed through built-in software." Wenn du dem Brandon, das ist der Kommentarautor, jetzt glauben würdest, dann hat er gerade gesagt, Dropbox braucht man eigentlich nicht. Und es gibt ja schon alles, deswegen kaufen wir die Lösung nicht. Und siehe da, ich glaube Dropbox ist eine sehr erfolgreiche Firma, die ich auch sehr dankend nutze. Ich finde diese Story schön und die erinnert mich irgendwie so ein bisschen an die Diskussion, die wir hier führen, denn wenn der Brandon und der Dropbox-Founder diese Podcast jetzt gehört hätte, bevor sie Dropbox gebaut hätten, denkst du Dropbox wäre erfunden worden?

Wolfi Gassler (01:07:23 - 01:08:02)

Also ich will jetzt nicht einen komplett neuen Themenblock nochmal aufmachen, aber da ist schon ein Punkt in der Geschichte, der natürlich sehr relevant ist, die Art der User und Das ist natürlich auch ein großes Problem, dass wir technischen Leute immer aus unserer Sicht denken. Und für uns ist es vielleicht machbar mit FTB und SVN und keine Ahnung, was für Technologien du noch aufgezählt hast. Aber es gibt natürlich auch andere User und für die ist es dann vielleicht wesentlich einfacher, Dropbox zu verwenden. Und man muss auch mit diesen Leuten zusammenarbeiten. Und wenn man dann als technische Person irgendwie einen FTB-Link mit irgendwem sharen muss, dann wird es vielleicht auch schmerzvoll, auch wenn wir es unter Technikern vielleicht hinbekommen.

Andy Grunwald (01:08:03 - 01:08:13)

Liebe Hörerinnen und Hörer, lasst euch also von dieser Folge nicht unterkriegen. Macht es wie Wolfgang, baut ein eigenes Meetup-Anmeldesystem oder baut das nächste Roblox. Steht für eure Idee ein.

Wolfi Gassler (01:08:14 - 01:08:24)

Und probiert es mal gerne aus, wenn ihr beim Meetup vorbeikommen wollt. Geht auf die Meetup-Seite engineeringkiosk.dev unter den Meetup-Section und da könnt ihr gerne mal eine Anmeldung machen.

Andy Grunwald (01:08:24 - 01:08:29)

Ich hoffe, ihr hattet ein wenig Spaß. Ich hatte ein wenig Spaß über Hackernews-Kommentare.

Wolfi Gassler (01:08:29 - 01:08:31)

Nur ein wenig.

Andy Grunwald (01:08:31 - 01:08:36)

Ja, nur ein wenig, denn ab und zu war es so ein bisschen negativ. Aber ich finde es unglaublich schön.

Wolfi Gassler (01:08:36 - 01:08:38)

Ich bin immer noch sehr negativ diesbezüglich. Bin voll negativ.

Andy Grunwald (01:08:39 - 01:08:48)

Ich find's halt geil, du kannst dich eigentlich überhaupt nicht aus dem Fenster lehnen. Du hast grad das Beispiel von Not Invented hier gemacht und argumentierst die ganze Zeit dagegen. Ja?

Wolfi Gassler (01:08:48 - 01:08:52)

Also ich ... Ah, das war nur Learning. Das war eine Learning-Session.

Andy Grunwald (01:08:52 - 01:09:16)

Die Standard-Los-Rede. Das war's mal wieder von uns. Wenn ihr uns ein bisschen was Gutes tun wollt, um diesen Podcast supporten wollt, dann geht doch mal nach Apple oder Spotify, drückt doch mal nach einem Daumen hoch, bewertet diesen Podcast und empfiehlt diesen an niemanden weiter, der diesen Podcast noch nicht hört. Das würde uns super helfen. Vielen Dank dafür und wir hören uns nächste Woche wieder. Bis später. Tschüss. Ciao.