Transkript
Sven Johann: Herzlich willkommen bei einer neuen Folge des INNOQ Podcasts. Heute diskutiere ich mit Jörg Müller und André Aulich, warum alles viel zu kompliziert ist. Wir haben proprietären Quatsch, wir haben Oberingenieur der SPAs, wir haben Microservice Katastrophen, Kubernetes Katastrophen. Und wir wollen diskutieren, warum das so ist und was wir dagegen tun können. Willkommen, André und Jörg.
Jörg Müller: Hallo.
André Aulich: Hallo, Sven Johann:.
Sven Johann: André, wer bist du? Und was machst du bei ihnen?
André Aulich Ich bin Senior Consultant bei INNOQ. Beschäftige mich viel mit Enterprise Architektur Themen und insbesondere mit der Ausrichtung von Architektur und Organisation.
Sven Johann: Jörg?
Jörg Müller: Ich bin Principal Consultant bei INNOQ und bin seit ungefähr sieben Jahren dabei. Ich habe die Softwareindustrie seit etwas über 20 Jahren aus den ganz unterschiedlichen Perspektiven begleitet, in den letzten Jahren relativ stark auf das Thema IT Architektur geschaut, in unterschiedlichen Phasen der Produktentwicklung, auch aus einer Sicht allein mit dem Business und unterschiedliche Phasen von Unternehmen begleitet, Startups wie auch etablierte Unternehmen und da teilweise aber sehr ähnliche Beobachtungen gemacht. Und deswegen freue ich mich, hier heute dabei zu sein.
Sven Johann: Ja, irgendwie ist alles Mist. Alles ist vielleicht ein bisschen übertrieben, aber wir würden jetzt einfach mal ein paar Beispiele nennen, was uns in unserem Projektalltag an Überkomplexität auffällt und was wir da so sehen. Die Frage ist ja, wie kommt es dazu, dass alles gefühlt zu kompliziert ist? Also wir stehen morgens nicht auf und sagen, wir wollen jetzt hier überbordende Komplexität haben. Und ich denke mir halt, wenn ich so auf meine Projekte schaue, wir haben Produktlinien gebaut, wo man eigentlich keine Produktlinie haben will. Produktlinien bringen immer erhebliche Überkomplexität mit sich, also es kann zu überkomplexem Configuration Management führen. Das wurde dann am Ende komplett eingestellt. Ich habe Projekte, wo wir viel zu viele Umgebungen haben, wo man sich fragt, wieso? Also da wurde ein eigenes Dependency Injection Framework gebaut. Wir hatten autonome Teams, und autonome Teams sind eigentlich eine gute Idee, in Verbindung mit einer minimalen Makroarchitektur, aber dann hat halt jeder seine eigene relationale Datenbank gehabt, seine eigene Deployment Pipeline. Also alles explodiert. Und das hat zu erheblichen Problemen natürlich geführt. Jörg, hast du auch ein paar Beispiele?
Jörg Müller: Ja, klar. Es ist schon interessant, wie viele Beispiele du gleich direkt dort rausholen kannst. Ich habe halt auch in vielen Projekten solche Situationen erlebt, meistens in Situationen, wo wir schon relativ lange gewachsen sind, wo mehrere Teams beteiligt waren etc. Und da sind dann Dinge, wie gerade damals, als die NoSQL Datenbanken populär waren, dass ich erlebt habe, dass man fünf Teams hat und die haben sechs verschiedene Datenbank Technologien im Einsatz. Ich war damals sehr oft für das Thema DevOps zuständig, was dann im Betrieb absoluter Albtraum ist. Wie organisiere ich dort Backups und ähnliche Dinge, wenn ich eine solche Umgebung habe? Ich habe relativ häufig tatsächlich auch viele Microservice Architekturen gesehen, die gerade so im synchronen Bereich unterwegs waren, die dann wahnsinnig viele Zeremonien gebraucht haben. Jedes Mal, wenn eine Microservice eingeführt worden ist, weil dort eben auch wieder über den Betrieb nachgedacht werden musste, weil das Monitoring extrem kompliziert war, was dort gemacht wurde und ich glaube, man kann tatsächlich auch wenn man nach draußen schaut und sich prominente Beispiele anschaut, das eine oder andere sehen, wo Komplexität auftritt, die wahrscheinlich irgendwo ein bisschen über das Ziel hinausgeschossen ist. Ein Beispiel, bei dem ich mit mir ein wenig streite das zu nennen oder nicht, ist tatsächlich Twitter. Ich finde es ganz schlimm, was da gerade passiert, aber das hat verschiedene Ursachen und ich finde auch die Art und Weise, wie dort mit den Mitarbeitern umgegangen worden ist, ganz schlimm. Trotzdem ist es interessant zu sehen, dass dort ein Unternehmen fast 80 % seiner Belegschaft verloren hat oder sogar noch mehr. Und letzten Endes die Plattform trotzdem einigermaßen ähnlich weiter funktioniert, wie sie vorher funktioniert hat. Oder ein anderes sehr prominentes Beispiel ist gerade Basecamp, die sich aus der Cloud zurückziehen und eigene On-Premise Infrastruktur schaffen und dort dann sehr viel Geld sparen. Also das ist der Punkt, den sie auch kommunizieren, was sicherlich neben der Cloud selbst auch was damit zu tun hat, dass sie Dinge vereinfachen, die vorher vielleicht einfach komplizierter waren. Also es gibt eine Menge Beispiele hier draußen und es gibt ja auch eine Menge Leute, die unter dem Stichwort Radical Simplicity oder ähnlichen Dingen propagieren, dass man einfach wieder ein bisschen zurück muss und Dinge einfacher gestalten muss, als sie häufig gerade in der aktuellen Realität sind.
Sven Johann: André, was sind deine Katastrophen?
André Aulich: Das Schöne ist, dass sie ja nie als Katastrophe anfangen oder selten zumindest. Und ich denke gerade an eine Situation, da hatten wir mehrere Produktteams ungefähr zur gleichen Zeit aufgesetzt, die erst mal für sich relativ unabhängig entscheiden konnten, wie sie ihr Problem lösen, ihr Geschäftsmodell umsetzen und auch wirklich tolle Sachen gemacht haben. Und wie das dann so ist, sind diese Produkte unterschiedlich erfolgreich. Dann fing das an, dass ein Produkt so erfolgreich war, dass wir mehr skalieren mussten, dann auch angefangen haben, das auch aufzusplitten, mehr Leute dazu geholt haben, während andere Produkte halt nicht mehr so erfolgreich waren, die dabei waren. Und was uns da sehr aufgehalten hat, dass wir sehr unterschiedliche Text Dec hatten. Das heißt, wir konnten nicht einfach Leute aus einem Team, das jetzt nicht mehr so gebraucht wurde mit der Geschäftsanwendung in ein anderes bewegen, weil einfach komplett andere Text Dec vorhanden war. Und das hat insgesamt von außen betrachtet die Komplexität für uns als Unternehmen erhöht, weil es halt schwieriger ist, dann schnell Leute einzuarbeiten, um eine kurze Time to Market weiterhin zu gewährleisten. Ein anderes Thema: Ich habe lange im Fernsehumfeld gearbeitet und dort System Architekturen und Gesamtarchitekturen mitgestaltet und da war es häufig das Thema, dass die verschiedenen Anwendungen ganz unterschiedliche Videoformate verwendet haben und auch Metadaten Formate, die beschrieben haben, was ich eigentlich in meinen Videodateien verarbeite. Und das führte dazu, dass innerhalb eines Unternehmens dann Daten übergeben werden mussten. Wir mussten unglaublich viel Middleware schreiben, die sowohl Datenformate transformiert, also Videodaten, was sehr aufwendig auch ist und Metadaten. Und das führte eigentlich bei fast jedem Unternehmen dazu, dass man sich dann irgendwann auf ein Haus Standard mindestens einigen wollte und dann am besten auch noch alle Zulieferer dazu holt. Und ich glaube, das ist bis heute noch eine Herausforderung. Da hätten Standards geholfen manchmal.
Sven Johann: Ja, die Frage ist, was meint ihr? Gibt es da Gemeinsamkeiten? Kann man da aus all den Beispielen irgendwie was rausziehen, können wir kategorisieren?
Jörg Müller: Also Komplexität tritt ja an vielen unterschiedlichen Stellen auf. Was uns aber aufgefallen ist, es gibt so einen relativ typischen Punkt, dass man irgendwie ein starkes Wachstum hinter sich hat. Man hat ein Produkt, das Produkt wächst relativ stark, man kommt dann irgendwann in so einem Punkt hinein, dass man sich wundert und denkt: Okay, die Dinge gehen nicht mehr so schnell, wie sie früher mal gegangen sind und irgendwie könnte das alles auch einfacher sein. Man hat also sein Produkt entwickelt, man ist gewachsen, man ist groß, man hat wahrscheinlich viele Teams, aber irgendwie fühlt sich das alles ganz schön kompliziert an, an der Stelle. Und die fachlichen Themen rücken immer mehr in den Hintergrund. Und ich glaube, das ist ein Punkt, auf den man sich konzentrieren kann. Es gibt also ganz viele verschiedene Zeitpunkte, wo Komplexität eine Rolle spielt. Aber ich glaube, der tritt immer mal wieder auf. Und er schlägt auch gerade bei uns in unserem täglichen Geschäft wird er sehr häufig relevant kundenseitig.
Sven Johann: Was sind die Gründe? Wieso kommen wir in diese Situation?
André Aulich Ich glaube, da gibt es ganz viele verschiedene Ursachen. Ich glaube, was ein ganz wichtiger Punkt ist, wir werden zu jedem Zeitpunkt, wo wir etwas gestalten, schauen, dass wir die angenommenen Anforderungen erfüllen. Das heißt, wir schauen, was soll das Produkt eigentlich machen? Wir werden nicht weniger tun als das, was wir benötigen, aber vielleicht mehr, weil in dem Moment, setzen wir unseren Fokus darauf, die Anforderungen zu erfüllen. Die ändern sich im Laufe der Zeit. Vielleicht ist ein Produkt viel erfolgreicher als wir dachten und unsere Skalierung muss jetzt nachgerüstet werden. Vielleicht ist es aber auch weniger erfolgreich und wir haben einen kybernetischen Cluster aufgebaut, den wir vielleicht gar nicht brauchen, weil wir merken, die Load ist gar nicht so oder vielleicht ist es erfolgreich, aber skaliert anders. Also unsere Annahmen ändern sich im Laufe der Zeit, glaube ich.
Sven Johann: Wenn es zu komplex wird, weil ich Erfolg habe, ich glaube, das sind Probleme. Also, ich stimme dir zu, das ist ein Grund, aber ich kann mir so ein paar Sachen auch vorstellen, wie ein Resume Driven Design oder so Computer Oriented Portfolio Management, also dass man einfach unreflektiert irgendwas macht. Also wir haben die Probleme, weil wir noch nicht mal so viel Erfolg haben, sondern weil wir einfach nicht richtig nachdenken.
Jörg Müller: Ich glaube, es gibt wirklich beides. Ja, du hast recht, es gibt diesen Effekt oder Hype Driven Development, es gibt Millionen Namen dafür, wo Leute einfach Dinge machen, weil sie gerade Spaß haben und weil sie vielleicht gar nicht so viel Spaß an der eigentlichen Domäne haben. Und sie wollen halt einfach was ausprobieren oder glauben, dass das später im Lebenslauf besonders gut aussieht, wenn sie Kafka oder Kassandra als Datenbank drinstehen haben. Ich glaube tatsächlich, das tritt weniger auf da draußen, als wir denken. Ich glaube, das Problem, was André beschrieben hat, nämlich dass ich Entscheidungen oder dass ich versuche, Dinge möglichst schlau und möglichst flexibel aufzubauen und im Wachstum das Ganze entsprechend mache, also, was ganz typisch auch ist für eine heutige moderne Architektur, dass ich mit autonomen Teams arbeite, die möglichst viel Freiraum haben, damit sie möglichst schnell Entscheidungen treffen können. Das ist etwas, was aus meiner Sicht zwangsläufig in eine gewisse Komplexität hineinführt. Und ich glaube auch, dass es ganz wichtig, dass man versteht, dass man das akzeptiert. Es ist halt einfach so, das passiert, diese Komplexität passiert. Man muss nur zu irgendeinem Zeitpunkt mal wieder raufschauen und sie wieder vereinfachen können. Ich finde da immer sehr schön diese Einfachheitskurve von Gunter Dueck an der Stelle. Und da geht aus meiner Erfahrung fast jedes System irgendwie durch. Also man fängt immer irgendwie sehr einfach an, das ist wie so eine Glockenkurve, ich muss das ja im Podcast jetzt beschreiben, wie so eine typische Wahrscheinlichkeitsverteilung irgendwo am Anfang der Zeitlinie fängt man an mit so dumm einfachen Prinzipien da kennt man seine Anforderungen noch gar nicht. Man macht das so ganz primitiv und simpel. Das wird dann irgendwann gut genug, dann ist es ganz okay und dann haben wir irgendwann unsere ganzen Anforderungen richtig verstanden, dann ist es ganz komplex und dort von dem Punkt, da muss man dann aber auch wieder runterkommen. Das passiert nicht immer, aber sollte eigentlich immer passieren, nämlich in Richtung einer smarten Lösung. Und wenn ganz toll wird, einer genial einfachen Lösung. So ist diese Kurve beschrieben. Also wenn man verstanden hat, was die Probleme eigentlich sind, was man wirklich lösen muss, dann zu Lösungen zu kommen, die wirklich einfach sind, diese Vereinfachung des Ziels, das finde ich sehr wichtig. Aber auch zu verstehen, dass es halt wahrscheinlich normal ist, dass man erst mal über den Berg muss.
Sven Johann: Mir fällt da immer Martin Fowler dazu ein, er hat ja diesen Spruch: Jetzt wissen wir, wie wir es hätten tun sollen. Ich glaube, das ist irgendwie normal. Wir müssen einfach mal loslegen. Wir werden die Dinge falsch machen und dann müssen wir aber auch erkennen, dass wir sie falsch machen. Aber was mich tatsächlich wundert, also klar, das schon, aber ich rege mich halt immer über andere auf. Vielleicht sollte ich mich mehr über mich selbst aufregen. Aber vielleicht noch ein Punkt: Wie seht ihr das, dass irgendwie zu viel Geld im Spiel ist? Es gibt zu viele mächtige Stakeholder, die ihre Sachen durchdrücken. Vielleicht auch dieses berühmte wir müssen jetzt dieses teure Tool nutzen, weil irgendjemand mit viel Geld hat auf dem Golfplatz uns dieses Tool verkauft. Verstehe ich das richtig? Das passiert, aber passiert eigentlich nicht so oft. Ist eigentlich vernachlässigbar.
Jörg Müller: Mh ja, zu viel Geld ist tatsächlich ein Problem. Also nicht, wenn ich das hätte, glaube ich. Weiß ich nicht genau. Das ist ganz kurios. Das ist nicht intuitiv, aber es ist tatsächlich so, dass ein Projekt, was zu viele Ressourcen hat, dazu neigt, ganz viele Dinge zu machen, die eigentlich mit dem eigentlichen Problem nichts mehr zu tun haben und dann das Ganze noch viel komplexer macht. In Startups versucht man das ja oftmals zu begrenzen, indem man sagt, man hat eben nur ein bestimmten Topf Geld und mit dem muss man auskommen und mehr gibt es erst mal nicht. Und das kann helfen, kreative Lösungen zu finden. Also insofern zu viel Geld ja, kann auch ein Problem sein.
André Aulich: Ich glaube, das hat auch ein bisschen was mit dem Mythical Man Month zu tun. Wo man sagt, nimm doppelt so viele Leute und du wirst doppelt so schnell fertig letztlich. Ich glaube, das verlockt dann tatsächlich auch sehr leicht zu sagen: Oh, wir haben jetzt so eine enge Deadline, lass uns einfach mehr Leute dazuholen, statt zum Beispiel an der Organisation oder der Technologie zu arbeiten.
Sven Johann: Ich muss gerade ein bisschen weinen, weil es ist schon interessant. Das Buch kam vor über 30 Jahren raus. Ich habe mich mal bei einem Kunden darüber aufgeregt, wir hätten eigentlich 50 Leute weniger gebraucht, aber wir haben stattdessen 30 Leute mehr eingestellt. Mit der Begründung irgendwas müssen wir ja tun, um schneller zu werden. Was aber jetzt natürlich nicht geholfen hat. Also ich denke auch, das ist relativ unintuitiv, aber vermutlich auch schwer zu argumentieren, dass man sagt, wir werden schneller, indem wir einfach weniger tun mit weniger Leuten und uns auf irgendwas fokussieren.
Jörg Müller: Genau, dabei ist es eigentlich genau der richtige Weg. Wenn man Dinge vereinfachen will, muss man weniger tun und nicht mehr tun und vielleicht weniger Leute brauchen als mehr Leute. Aber gut, da kommen wir in eine Lösungsdiskussion rein.
Sven Johann: Okay, ich versuche mal zusammenzufassen. Ergänzt mich gerne. Also was ist eigentlich das Problem, dass die Dinge zu komplex sind? Wir stehen nicht still, aber wir haben dieses subtile Gefühl, alles könnte einfacher sein. Vielleicht ist es auch nicht nur subtil, sondern es gibt ja dieses Ding WTF/Minute oder so, also dass man irgendwie denkt, es geht schon vorwärts, aber irgendwie denkt jeder: Ach, es dauert zu lange. Dann hast du André gesagt, es wird mehr gebaut, als wir brauchen.
André Aulich: Weniger fällt leichter auf als mehr.
Sven Johann: Aber so in dem Sinne, wir bauen zu viele Dinge, deren Wert zweifelhaft ist so ungefähr.
André Aulich: Im Prinzip schon. Es ist natürlich nicht immer so, aber es kann schon leicht passieren, dass du sagst, wir beginnen ein neues Produkt und du hast große Hoffnungen, wie erfolgreich das mal sein wird, wie viele Benutzer es haben wird. Und du triffst Annahmen, dass wahrscheinlich eine große Skalierung notwendig sein wird und bereitest dein System vielleicht architektonisch so vor, dass eine Skalierung auch sehr leicht möglich ist. Hinterher merkst du aber, du hast das vielleicht alles ganz anders geschnitten hat, Technologie eingeführt für eine Annahme, die sich so nicht erfüllt hat, die vielleicht ganz anders umgesetzt werden kann, was aber keine schlechte Entscheidung gewesen sein muss zu dem Zeitpunkt, als es entstanden ist. Aber die Dinge haben sich geändert. Du hast halt viel gelernt, wie dein Produkt angenommen wird, wie die Leute damit interagieren und merkst, dass es bessere Wege gibt, die vielleicht sogar einfacher sind. Also zumindest bezogen auf die Anforderungen. Und dann macht es Sinn, ab und zu mal drauf zu schauen und zu sagen: Jetzt räume ich ein bisschen auf und passe das an, an die neuen Anforderungen. Ich glaube, das Spannende auch in dieser Diskussion ist gar nicht zu sagen, dass jemand was falsch gemacht hat oder dass irgendwo der eine Punkt kommt, wo man sagt, jetzt auf einmal ist es zu schwierig, damit umzugehen. Ich glaube, das wirst du immer haben. Du wirst eigentlich in der gesamten Produktphase sehen, Dinge könnten einfacher sein, aber sie sind halt nicht immer gleich wichtig. Manchmal ist es wichtiger, erst mal neue Features hinzuzufügen und zu sagen, wir müssen jetzt das Produkt ausbauen und für den Kunden wirklich attraktiv machen. In der Phase ist es vielleicht nicht das Interessanteste zu sagen, lass es für uns erst mal einfacher machen. Aber irgendwann kommt der Punkt, dass du merkst, dieses einfacher machen für uns, die das entwickeln, ist auf einmal das Wichtigste, was wir tun können, weil wir sonst keine neuen Features mehr leisten können. Das ist meistens in einer bestimmten Prduktphase erst der Fall. Und das finde ich sehr spannend, dass wir das austarieren müssen mit anderen Prioritäten.
Sven Johann: Okay, ich habe mich beruhigt und denke: Okay, so wie es läuft ist es zu kompliziert, zu komplex. Aber so ist es halt und jetzt muss ich handeln. Jetzt frage ich mich halt, ich habe ja immer die Situation, wie gehe ich da ran, wenn ich merke, es wird alles zu zäh? Was würdet ihr empfehlen?
Jörg Müller: Ja gut, es ist wie jedes andere Problem eigentlich. Ich muss erst mal analysieren, was ist eventuell mein Problem. Ich muss das Ganze auch irgendwie beurteilen, das heißt ich muss priorisieren. Ich kann ja nicht einfach alles einfach auf ein Schnips einfacher machen. Das wäre schön, wenn ich das könnte, sondern ich muss erst mal herausfinden, was sind eigentlich die Punkte und wo lohnt es sich meine Energie reinzustecken? Dann gibt es bestimmte Dinge, die man vereinfachen kann. Und klar, man muss es auch irgendwie umsetzten. Also Analyse, irgendwie das Ganze beurteilen und das tun letzten Endes sind die Dinge. Spannend ist, herauszufinden was sind denn jetzt Punkte, wo sich es wirklich lohnt zu vereinfachen? Und da kommt eine andere ganz interessante Theorie ins Spiel, weil die Frage ist ja wann ist etwas zu kompliziert? Das ist ja eine spannende Frage. Also ich kann bei jedem beliebigen Ding sagen, ist es jetzt zu kompliziert oder ist nicht kompliziert? Für die eine Person ist es zu kompliziert, für die andere Person ist es nicht so kompliziert. Das sind ja ganz verschiedene Dinge und ich kann da wahrscheinlich nichts absolut wirklich ansetzen. Was uns da zu Hilfe kommt als Modell, um darüber nachzudenken, ist die Idee des Cognitive Load. Wenn jemand das Buch Team Topologies kennt, da wird auch relativ viel darüber gesprochen. Das bezieht sich auf eine Theorie, die eigentlich aus der Pädagogik kommt oder aus der Psychologie. Aber dort geht es vor allem um Lernen von Inhalten. Um das mal ganz kurz zusammenzufassen: Da geht es um den Gedanken oder um die Idee, dass unser Gehirn, wenn es etwas verarbeitet, nur einen begrenzten Arbeitsspeicher hat für uns. Die meisten hier werden ja Informatiker sein, können sich darunter vermutlich was vorstellen. Da passen also tatsächlich nur so ein paar Dinge parallel rein. Man redet von fünf bis sieben Chunks üblicherweise. Und Chunks ist quasi wie eine Idee. Also die Idee, etwas ist ein Auto. Das ist jetzt eine Idee und ein Ort ist eine andere Idee und kann also fünf bis sieben solche Dinge im Kopf behalten, um etwas zu lernen oder um ein Problem zu lösen. Also man kann es so interpretieren, dass man das auf das Problemlösen verwendet. Das heißt, es wird immer dann kompliziert, wenn ich nicht in der Lage bin, das in meinen Kopf hineinzukriegen, weil dann muss ich in der Lage sein, das Problem erst auseinanderzuschneiden usw. Und dann wird es zäh, dann wird es langsam, dann dauert es längere Zeit. Das heißt, da muss ich dran. Also, ich muss diese Menge der Dinge, die ich verstehen muss, irgendwie reduzieren, oder ich muss dafür sorgen, dass die Dinge, die ich da verstehe, sich besser zusammenfassen lassen, abstrahieren lassen. So viel zu dieser lustigen Theorie da ringsrum. Jetzt die Frage: Wie kann man die anwenden? Oder wie merkt man da was? Und das merkt man, indem man mit den Leuten spricht und schaut, was sind Sachen, die wirklich zäh sind, die sich zäh anfühlen, wo ich lange darüber nachdenken muss, wo es schlimm ist, wenn ich unterbrochen werde und ähnliche Sachen. Und das können Leute meistens relativ gut und relativ schnell feststellen. Da gibt es jetzt alle möglichen klassischen Methoden, Interviews, was immer ganz toll ist, mit HR Coaches zu reden, weil die wissen meistens ganz genau, wo ihre Teams gerade Schwierigkeiten haben oder Umfragen zusammenbauen formell oder weniger formell. Das sind alles Dinge, mit denen man rausfinden kann, was sind eigentlich Dinge, die zäh sind und wo kann man eventuell ansetzen, diesen Load zu reduzieren?
Sven Johann: Okay, jetzt habe ich die Interviews geführt, also ich mache ja auch öfter Interviews und ich muss auch sagen, ich bin immer froh, diese Interviews zu machen, weil zum einen jeder hat ja so eine subjektive Meinung, was verbessert werden sollte und mit Interviews bekommst du eine objektivere Meinung. Und ist natürlich auch so ein Baking für Veränderung, weil wenn sich 50 % der Leute sich beschweren, wenn die Sachen immer wieder hochkommen, ist normalerweise ein Willen da, das zu verändern. Aber ich muss dazu sagen, die Interviewspanne ist immer sehr breit. Was ich hier ganz gut finde, ist halt dieser extreme Fokus auf Vereinfachung, also dass wir tatsächlich sagen, also nicht nur irgendwie, was stört euch, sondern was könnte einfacher sein. Okay, jetzt haben die Leute geantwortet, wir haben irgendwie diese fünf oder sechs Datenbank Technologien, die du genannt hast oder wir haben zu viele Programmiersprachen und dann sagen die Leute: Ja, mich nervt total, dass ich da ständig zwischen JavaScript und Go hin und her wechseln muss oder jetzt muss ich ein Backup für MongoDB machen, drei Minuten später für PostgreSQL und noch mal eine halbe Stunde später für MariaDB. Jetzt habe ich diese Infos und du hast eben nochmal gesagt, du musst irgendwie beurteilen, ob du jetzt was tust, wie würdet ihr das beurteilen?
André Aulich: Es hängt ein bisschen von den Prioritäten ab, die du gerade gesetzt hast, in der Phase, in der dein Produkt auch ist. Wenn es gerade zum Beispiel extrem wichtig ist, Features zu liefern, dann könnte sein, dass Kosten an der Stelle noch nicht so relevant sind, sondern die Time to Market. Dann könntest du zum Beispiel Durchlaufzeiten von Features messen. Du könntest auch sagen, hier geht es aber eigentlich doch gerade um Kosten, weil in der anderen Phase Wettbewerb tritt in den Markt ein, du musst die Kosten senken, dann schaust du vielleicht was kosten die Produkte, die ich einsetze? Kann ich mich auf ein günstigeres einigen, was dann vielleicht alle nutzen oder sowas halt. Das heißt, für die Kriterien, die gerade relevant sind, einmal identifizieren und daran die Möglichkeiten bemessen.
Sven Johann: Also im Grunde genommen, wenn ich auf das Datenbank Problem schaue, also wenn gerade Time to Market mein Problem ist, könnte ich theoretisch sagen, ich stell einfach mal noch ein paar Leute ein, okay, das führt dann wiederum zu anderen Problemen, aber okay.
Jörg Müller: Wenn dein Ziel da an der Stelle die Vereinfachung ist, man kann halt verschiedene Dinge tun, um etwas zu vereinfachen. Wir hatten vorhin schon mal dieses Thema, die Golfplatz Lösung ist oftmals ein neues Tool anzuschaffen. Die ist aber selten eine gute Lösung, sondern eher schaust du in die Richtung, dass du sagst, du möchtest Dinge einfach weglassen. Wenn ich also zu viele Datenbanken habe, kann ich mir überlegen, brauche ich die alle? Ist es nicht so, dass vielleicht zwei von diesen Datenbanken fast dieselbe Rolle erfüllen und ich mit minimalen Unterschieden, dass ich einfach reduzieren könnte und sagen könnte: Gut, ich habe eben nur dann schon mal eine Datenbank weniger im Einsatz, dann muss ich mich bei einer Datenbank weniger um Backups kümmern, um Disaster Recovery kümmern, um verschiedene andere Dinge. Das heißt, weglassen ist immer ein guter Schritt. Was ich auch machen kann, ich kann hingehen und sagen, ich versuche Dinge zu automatisieren oder zu delegieren. Da kommt dann vielleicht das Tool Problem in den Raum. Vielleicht ist ein Tool auch eine Lösung, wenn es mir erlaubt, jetzt sind wir wieder bei diesen Chunks, also wenn es mir erlaubt, einen komplexen Vorgang, wo ich mir ganz viele Dinge merken muss, auf mehr oder weniger einen Knopfdruck zu reduzieren, dann ist das Problem für mich vielleicht leichter und ich komme damit auch schneller voran. Ja, oder wenn wir bei diesem Cognitive Load Thema sind, im Zweifelsfall auch sagen: Okay, da muss halt trainiert werden, dann muss halt geübt werden. Das kenne ich sehr gut aus dem Umfeld von zum Beispiel Incident Management. Da kann man selten wirklich was automatisieren, weil immer irgendwas anderes kaputt geht meistens außer man automatisiert den Neustart. Aber da muss man halt genau untersuchen können, da kann man die jeweiligen Schritte halt einfach trainieren, bis sie quasi ins Muskel Gedächtnis übergehen und man dann dadurch die Probleme auch deutlich besser lösen kann.
Sven Johann: Automatisieren, delegieren von unseren, ich sage mal von den Katastrophen, die wir am Anfang genannt haben, hätten wir dann zufälligerweise ein Beispiel? Beim Weglassen da fällt uns viel ein, aber automatisieren, delegieren?
André Aulich: Automatisieren wäre zum Beispiel bei den Video Formaten möglich. Das ist der typische Ansatz, dass man Transformationen halt automatisch durchführen lässt. Delegieren? Haben wir in dem Team, was ich vorhin erwähnt habe, wo wir mehrere Teams in unterschiedlichen Text Decs hatten. Alle haben mit Identity Management zu tun, das haben irgendwann vor die Klammer gezogen. Das ist auch eine Art von Delegieren, das heißt, wir haben ein neues Team gegründet, das Expertenwissen in einem Bereich aufgebaut hat und dadurch war das Thema quasi aus den Köpfen der anderen Mitglieder.
Jörg Müller: Im Bereich von so großen Netzwerken, von synchronen Microservices ist es natürlich eine Möglichkeit zu sagen okay, diese ganzen Seiten Aspekte wie Monitoring, wie Ausfallsicherheit, Resilienz etc. kann man automatisieren über Dinge wie zum Beispiel Service Measures oder verschiedene Libraries. Ich sage kann man, es wäre mittlerweile glaube ich nicht meine erste Lösung, die ich einsetzen würde, sondern ich würde da eher schauen, brauche ich denn eigentlich diese vielen synchronen Services oder kann ich das nicht anders machen und durch Weglassen hinzugehen, ich bin ein großer Fan von weglassen, das habe ich ja schon geäußert, aber das wäre halt auch eine Automatisierungslösung, die ich dort machen kann.
Sven Johann: Ich bin ja auch ein großer Freund von weglassen, aber ein Problem gibt es immer in der Argumentation, und zwar ich weiß nicht, ob ich das jetzt richtig herleite, aber es gibt die sunk cost fallacy. Also jetzt haben wir schon so viel Geld in Training von diversen Datenbank Technologien gesteckt jetzt müssen wir das Know How auch pflegen. Und wenn wir jetzt einfach sagen: Wir werfen einfach Dinge weg und konzentrieren uns auf weniger Technologien, wie ist euer Gefühl da? Ist das einfach oder gibt es da Gegenwind zu erwarten?
Jörg Müller: Ja, Gegenwind gibt es da natürlich häufig. Die Dinger heißen ja nicht umsonst fallacies und sind sehr populär. Und ja, sunken cost ist immer ein typisches Thema. Wir haben so viel Geld dafür ausgegeben, das können wir doch jetzt nicht einfach so wegmachen. Es ist tatsächlich etwas, wo man oftmals etwas mehr Überzeugungsarbeit leisten muss zu sagen: Gut, aber denkt noch mal in die Zukunft, schaut nicht in die Vergangenheit, es ist völlig egal, ob ihr jetzt so viel Geld ausgegeben habt oder nicht, schaut in die Zukunft, schaut, was das in der Zukunft wahrscheinlich für Wirkungen hat mit all dem, was wir jetzt gelernt haben. Es sind ja verschiedene andere von diesem berühmten fallacies und bias, dass die da eine Rolle spielen. Hindsight bias ist ja auch sehr beliebt in dem Umfeld, was wir hier gerade diskutieren. Das heißt, im Nachhinein ist man immer schlauer. Natürlich weiß man jetzt, dass man das damals hätte anders machen können und dann wäre es vielleicht besser gewesen. Das heißt aber noch lange nicht, dass die Entscheidung damals falsch war, weil damals hatte man dieses Wissen von heute halt nicht. Und genauso ist sunken cost fallacy letztendlich genau andersrum. Also man hat halt das damals so gemacht. Das war jetzt keine falsche Entscheidung, aber deswegen muss man sich trotzdem anders versuchen zu retten. Das ist ganz wichtig in dem Zusammenhang.
Sven Johann: Um noch mal den Bogen zurück zu der Aussage von André ganz am Anfang zu spannen. Wir sind uns einfach immer bewusst, dass wir danebenliegen und dass wir anerkennen müssen und nicht an Lösungen festhalten, die damals gut erschienen, aber jetzt sind wir weiter und muss sozusagen einfach anerkannt werden. Es gibt so Überlegungen Training, automatisieren, delegieren, weglassen, gibt es noch irgendwelche weiteren Tools? Nicht, dass ich neue Tools einführen will, aber vielleicht Tools, Methodiken, die auch helfen zu verstehen, was wir vereinfachen können?
Jörg Müller: Eine Sache könnte ich noch ergänzen. Wir haben ja ein paarmal schon über unterschiedliche Text Decs oder gleiches Text Decs geredet. Jetzt ist ja immer ein bisschen schwierig zu definieren, was ist denn eigentlich ein Text Dec? Wir haben da eine relativ einfache Methode, das Ganze mal auf eine Seite zu bringen. Das nennt sich Text Dec Canvas, wo man so alle wesentlichen Elemente mal in so einer Checkliste drin hat, wo man sagt okay, was ist eigentlich meine Frontend Technologie, was ist Backend, was benutze ich in der Infrastruktur, was benutze ich zum Testen? Das hat die Erfahrung gezeigt, das ist eine relativ praktische Methode, gerade Team übergreifend ein Bild davon zu bekommen, was hat man eigentlich im Einsatz, weil das recht gut auch vergleichbar ist. Und dann kann man auch rausfinden, wo lohnt sich es vielleicht tatsächlich bestimmte Zusatz Services über eine Plattform anzubieten oder wo lohnt sich es vielleicht auch Trainings anzubieten, weil das funktioniert oder wo merkt man, da hat man ein paar so exotische Sachen im Einsatz, das ist vielleicht dann wieder ein Zopf, den man abschneiden sollte. Weil der nur an einer Stelle zum Einsatz kommt und kein anderer das versteht und es wahnsinnig viel Aufwand macht.
Sven Johann: Ich stelle mir jetzt gerade wieder so ein Training vor, aber das kann man durchaus auch als Workshop machen, die bereiten die Text Dec Canvas vor, da stehen alle Technologien und dann sollen Leute einfach mit so einem Dot Voting ihren Punkt draufstellen, was sie am meisten nervt.
Jörg Müller: Genau, oder was zum Beispiel auch gar nicht unüblich ist, wenn man zum Beispiel vermeiden möchte, dass man immer zu viele neue Technologien einsetzt und man startet ein neues Projekt, dass man sagt: Okay, was ist denn eigentlich so unser typischer Tex Dec im Unternehmen? Dann schaut man sich an, wie weiche ich in meinem neuen Projekt davon ab, welche neuen Dinge habe ich dort? Und dann kann ich relativ schnell sehen, ist das jetzt ein Projekt, wo ich viel Risiko habe durch neue Dinge oder bin ich dort auf einem realistisch handhabbaren Level?
Sven Johann: Ich muss da jetzt so an Scout 24 denken, weil die sagen ja auch, wir limitieren unseren Text Dec. Aber das Problem von limitieren vom Text Dec ist natürlich auch, das sagen die auch, ist alles auf GitHub nachlesbar, dass sie sagen, wie schaffen wir es trotzdem innovativ mit Technologien zu sein? Wir sind zwar limitiert, wollen aber trotzdem neue Dinge zulassen irgendwie müssen wir es ja managen.
Jörg Müller: Mir wäre halt auch wichtig, an der Stelle zu sagen, nur einfach alle Dinge vereinheitlichen also das, was man so klassischerweise früher gemacht hat, ist vielleicht der falsche Fokus. Deswegen haben wir dieses Thema Cognitive Load vorhin mal so ein bisschen rausgeholt, weil wenn ich zu viel standardisiere oder sage, ich möchte halt nur die oder jene Programmiersprache einsetzen, dann kann es passieren, dass ich meinen cognitive Load eigentlich damit erhöhe, weil ich dann plötzlich das Problem habe, dass ich zum Beispiel mit Java ein Machine Learning Problem lösen muss, was ich in Python vielleicht in zehn Minuten gelöst hätte, aber in Java erst mal die passende Bibliothek finden muss und die dann auch nicht so richtig leistungsfähig ist und die Geschwindigkeit dann vielleicht auch nicht stimmt. Also an alle Java Fans, bitte nicht falsch verstehen, aber in dem Bereich ist wahrscheinlich Python die bessere Lösung und in anderen Bereichen wäre Java die richtige Lösung. Und diese Flexibilität muss man schon haben. Also man sollte nicht sagen, einfach nur alles reduzieren, weil das kann am Ende sogar dazu führen, dass man den Load erhöht.
Sven Johann: Ja, sagen wir mal, der Text Dec wird einfacher, aber die Lösungen, die gebaut werden, werden viel komplizierter, weil der Text Dec einfach völlig ungeeignet ist. Okay, vielleicht noch ein Punkt zum Thema, also wir haben die Komplexität, wir haben jetzt diverse Maßnahmen gefunden, wir haben die Leute interviewt, wir haben beurteilt, was wir tun wollen,wir lassen Sachen weg, automatisieren, delegieren, drehen, trainieren, üben, nutzen Text Dec und dann? Also jetzt habe ich die Sachen, jetzt denke ich immer so: Ja klar, die Verbesserungen müssen irgendwie eingeplant werden, aber es gibt 123 andere Dinge, die auch eingeplant werden. Wie geht’s dann weiter?
Jörg Müller: Das ist ein Klassiker, das kennen wir ja auch von Technical Dept was ja immer gerne diskutiert wird. Was hat eigentlich mehr Mehrwert zu einem bestimmten Zeitpunkt? Das muss man natürlich priorisieren. Man nimmt sich einfach die Dinge vor, von denen man denkt, dass sie den besten Hebel haben und misst dann nach einer gewissen Zeit wieder, wie fühlt sich das Ganze denn jetzt an? Man kann ja auch mit der Vereinfachung übers Ziel hinausschießen. Irgendwann hat es vielleicht auch gar keinen Effekt mehr. Deswegen ja, ich glaube, das ist wie mit jeder anderen Sachen, die man dort einführt, so Schritt für Schritt iterativ und immer wieder draufschauen und messen und schauen, hat man die Zähigkeit jetzt überschritten? Ist man besser geworden an der Stelle oder nicht? Was wäre der nächste Schritt?
Sven Johann: Ich denke gerade dran beim Weglassen, ich würde natürlich jetzt erst mal einen kleinen Schritt machen. Okay, ich lasse jetzt mal die die MariaDB weg, fokussiere mich auf PostgreSQL so ungefähr. Also nicht zu viel auf einmal.
Jörg Müller: Ja, nicht zu viel auf einmal, aber trotzdem auch keine Angst haben, auch mal radikale Schnitte zu machen. Manche Dinge gehen nicht in kleinen Schritten.
Sven Johann: Was wäre so ein Beispiel dafür? Was geht nicht in kleinen Schritten?
Jörg Müller: Zum Beispiel so was wie, ich stelle fest, dass ich die Skalierbarkeit einer Cloud nicht brauche bzw. auch die Komplexität eines Kubernetes Clusters nicht brauche. Das habe ich jetzt rausgefunden, dann kann ich nicht Schritt für Schritt Kubernetes zurückfahren, sondern dann muss ich einfach sagen: Gut, ich setze meine neue Infrastruktur auf und lasse Kubernetes weg. Punkt.
Sven Johann: Das Basecap Beispiel sozusagen.
Jörg Müller: Genau, das geht in eine sehr ähnliche Richtung. Also sie gehen schon in gewissem Maße Schritt für Schritt aus der Cloud raus, aber sie haben eine klare Entscheidung getroffen und dann wird das halt so gemacht.
Sven Johann: Weil ich bin vorsichtig damit, weil ich denke immer so radikale Schritte da stößt man doch Leuten vor den Kopf. Wenn ich es schaffe, das peu a peu zu machen, okay, aber wenn man sagt, jetzt machen wir alles ganz anders, na ja, okay. Aber ich denke, ich bin einfach zu sehr ein Schisse, was das angeht. Andere Leute machen es halt einfach. Die sagen: So, jetzt weg von Open Shift, acht Monate machen X Leute nichts anderes und dann sind wir da weg.
Jörg Müller: Manchmal nutzt es sich, wenn man etwas einsetzt und man will es weglassen, sich sehr konsequent die Frage zu stellen: Was hat das denn jetzt eigentlich für einen Mehrwert für meinen Kunden, dass ich das und das benutze? Wenn die Antwort nicht wirklich gegeben werden kann, dann ist es vielleicht Zeit es nicht mehr zu tun.
André Aulich: Aber das ist auch ein interessantes Thema. Wer bemißt das eigentlich, ob das jetzt das Richtige war aus Einfachheitssicht? Also der Entwickler, der im Team ist, hat vielleicht gerade die Entscheidung nicht verstanden, weil sein Leben nicht einfacher wurde. Aber es wurden gerade andere Kriterien wichtiger, die halt gar nicht auf Einfachheit eingezahlt haben. Und ich glaube, das dann gut zu kommunizieren ist der Schlüssel. Das hatten wir auch einmal in einem Projekt, wo wir einmal eine komplette Architektur Entscheidung getroffen haben, die abhängig war von Kosten und Time to Market vor allem. Und nach einem Jahr wurde die Entscheidung komplett zurückgedreht und dieselben Entwickler blieben im Projekt. Das wurde tatsächlich verstanden, weil die Prioritäten im Unternehmen sich geändert hatten. Das Unternehmen hat eine ganz andere Phase durchgemacht und Dinge haben sich geändert. Und da war Entwicklung inhouse wieder wichtiger. Und dadurch wurde das dann auch mitgetragen von allen Entwicklern. Ich glaube, wenn Entscheidungen dann transparent sind und klar ist, dass die eigenen Interessen berücksichtigt worden sind, dann geht so was öfter. Vielleicht nicht die selbe Entscheidung fünf mal hintereinander, die jeweils umgedreht wird, aber ja.
Sven Johann: Tatsächlich hätte ich da auch noch ein Beispiel, aber okay. Ich würde mal auf den letzten Punkt kommen, der hat sich vielleicht schon so ein bisschen erledigt, weil ich habe mich halt gefragt, gibt es irgendwas, was man vorab tun kann, damit diese überbordende Komplexität nicht passiert? Jetzt haben wir ja schon am Anfang gesagt: Na ja, im Grunde genommen ist das ein normaler Lernvorgang. Ihr habt habt auch die Einfachheitskurve von Gunter Dueck erwähnt. Also wir lernen und irgendwann erreichen wir den Punkt, wo wir sagen: Okay, blöd gelaufen, jetzt sind wir schlauer, jetzt vereinfachen wir. Aber gibt es trotzdem Dinge, auf die wir achten können, damit es vielleicht nicht zu extrem wird? Gibt es irgendwelche Sachen, worauf man achten kann?
André Aulich: Ich glaube, was das schwer macht mit der Antwort, das ist der Grund, warum uns wahrscheinlich zu jedem Punkt auch immer gleich eine Ausnahme einfällt, wo es dann doch nicht so gut funktioniert, aber ich glaube tatsächlich, nicht zu viel zu machen, sondern wirklich überschaubare Annahmen oder Anforderungen erst zu adressieren, ist ein ganz wichtiger Punkt. Gleichzeitig will man aber als Architekt natürlich auch eine gewisse Flexibilität sich erhalten. Das heißt Entscheidung in die Zukunft verschieben und vorbereitet sein, falls sich Dinge ändern. Und ich glaube, da muss man irgendwann eine Risikobewertung halt einfach vornehmen. Zum Beispiel so ein Thema, was ich einmal erlebt habe, da haben wir ein Kubernetes Cluster On-Premise aufgebaut, zu einer Zeit, als es in der Cloud ein paar Klicks gewesen wären und hatten dann ganz viel Arbeit damit, dann, wenn Arbeitsspeicher nachgerüstet werden musste. Dann standen alle Entwicklungsprojekte still und so, es wurde Wissen aufgebaut. Es war unglaublich komplex, wurde am Ende nicht gebraucht, weil auf einmal war es datenschutzrechtlich möglich, in der Cloud zu arbeiten, was vorher nicht gesehen wurde für den Kunden. Das heißt, wir hätten uns das alles sparen können, hätten wir gewusst, dass irgendwann die Cloud für uns eine Option wird aus Daten Sicht. Aber hätten wir die Bewertung zu der Zeit anders treffen können, als wir uns entschieden haben, das On-Premise zu bauen? Wahrscheinlich schon, aber es war kein Muss. Es war durchaus im Lösungskorridor und ich glaube, sich Dinge bewusst machen und immer wieder mal diese Nebenthemen in den Fokus zu rücken, darüber nachzudenken und nachzujustieren. Das ist wichtig. Und das ist natürlich ganz am Anfang auch extrem wichtig. Genau wie später, wenn der Schmerzpunkt zu groß ist, Time to Market zu lang oder zu viele Ausfallzeiten, weil man die Komplexität nicht überblickt, dann muss man irgendwann sagen, das ist jetzt wirklich wichtiger als andere Themen. Und das ist natürlich ganz am Anfang, wenn ich ein Projekt aufsetze auch schon so.
Jörg Müller: Ich glaube, Mindset ist hier schon wichtig. Mindset im Sinne von YAGNI you ain’t gonna need it, im Sinne von wir wollen die Dinge trotzdem einfach halten, wir wollen Sachen nicht unnötig verkomplizieren. Also eine gewisse Widerstandsfähigkeit zu haben gegenüber komplexer werdenden Dingen ist sicherlich hilfreich. Aber letzten Endes, man muss halt irgendwann einfach eine Entscheidung treffen. Und es geht vielleicht gar nicht so sehr darum, Fehler zu vermeiden. Ich habe von dir, Sven Johann:, dieses Gregor’s Law gelernt von Gregor Hohpe. Das fand ich sehr interessant in dem Zusammenhang, der da sagt: Excessive complexity is nature’s punishment for organizations that are unable to make decisions. Das ist spannend. Komplexität folgt daraus, dass man eigentlich keine Entscheidungen treffen kann. Das heißt, man kann Komplexität vermeiden, indem man Entscheidungen trifft oder zumindest in die Richtung geht. Was insofern spannend ist, denn wenn ich die ganze Zeit keine Entscheidungen treffe, weil ich Fehler vermeiden möchte, dann führt das zu Komplexität. Das ist ganz interessant. Finde ich als einen lustigen Widerspruch in dem Ganzen. Wenn ich Komplexität vermeiden will auf Teufel komm raus. treffe ich keine Entscheidungen, was letztendlich zu Komplexität führt. Auch sehr spannend. Also insofern das Mindset ist wichtig. Aber ich glaube eben, genauso wichtig ist es, sich darüber klar zu sein, dass man bestimmte Dinge nicht vermeiden kann, sondern dass man da reinlaufen wird, dass man da gewisse Komplexität einfach nicht vermeiden kann, sondern dass man sie später einfach wieder senken muss, ist, glaube ich, ein ganz wichtiger Erkenntnis dabei.
Sven Johann: Du hast YAGNI genannt, als alter extreme Programmer, denke ich auch immer an YAGNI oder an the simplest thing that could possibly work. Und ich muss eben so ein bisschen grinsen, als André gesagt hat, du findest immer so ein Gegenbeispiel. Also Kent Beck, ich weiß nicht genau bei ihm YAGNI 100 % zuschieben kann, aber er ist ja einer der Leute, die vor 20 oder 25 Jahren da rumgerannt ist und YAGNI, YAGNI, YAGNI. Und lustigerweise hat er neulich so ein Tweet losgelassen, wo er gesagt hat: Ich bin hier gerade bei einer Lebensversicherung, bei so einem Bestandssystem und you ain’t gonna need it, du brauchst es einfach nicht. Und dann sagte er: Aber was ist, wenn du es doch brauchst? Also findest du immer die Gegenbeispiele. Aber okay, bewusstmachen und entscheiden.
Jörg Müller: Und im Zweifelsfall eben dann hingehen und zu einem bestimmten Zeitpunkt wissen, jetzt ist es wahrscheinlich wieder gut, mal wieder über Vereinfachung nachzudenken. Genau dann, wenn man das Gefühl hat, Mensch, alles, was wir da draußen tun, irgendwie könnte das einfacher gehen. Dann ist es vielleicht ein guter Zeitpunkt, sich das mal genauer anzuschauen und zu schauen, wo erzeugen wir jetzt eigentlich unseren Cognitive Load? Was macht es eigentlich gerade kompliziert und das ein bisschen bildlicher zu machen und dann mal zu schauen, ob man da wieder dran drehen kann.
Sven Johann: Vielleicht eine letzte Frage dazu von mir. Es gibt ja diesen The Last Responsible Moment für Entscheidungen. Da muss ich jetzt gerade denken, weil typischerweise verpasst man diesen Moment. Würdet ihr es drauf ankommen lassen? Also die Beschwerden blubbern langsam so nach oben, es wird immer mehr und dann merken wir es schon. Oder gibt es so den Quartals mäßigen Reminder, einfach noch mal eine Stimmungslage einzuholen?
André Aulich: Ich glaube, als Manager würde ich mir schon die Stimmungslage regelmäßig einholen, um schlimmere Situationen zu vermeiden. Wenn ich jetzt ein Produkt habe, was ich Kunden anbiete und die Kunden fangen an, sich zu beschweren, dass es überhaupt keine neuen Funktionen mehr gibt, dass die Ausfallzeiten höher sind und solche Dinge, das möchte ich vielleicht gar nicht. Oder das Produkt behält den Preis, während die Konkurrenz gerade viel günstiger wird. Und um so was im Vorfeld adressieren zu können, macht es Sinn, regelmäßig draufzuschauen. Wenn ich das erst abwarte, dann kommt das mit Kosten.
Jörg Müller: Und ich glaube, es ist wirklich wichtig, auch die die Experience der eigenen Entwickler oder aller, die an dem Entwicklungsprozess beteiligt sind, also das sind nicht nur Softwareentwickler, sondern eben auch Betrieb und POs, regelmäßig zu untersuchen. Also Retrospektiven ist ein grundsätzliches Mittelwert. Wer das nicht macht, ist wirklich sehr leichtsinnig und vielleicht auch wirklich regelmäßig Umfragen machen. Es gibt da draußen mittlerweile ein paar Tools, mit denen man regelmäßig so Developer Experience messen kann und sich dort ein Bild zu machen und zu schauen, ab wann wird das Ganze eigentlich schwierig, ab wann wird es eben zäh, diesen Moment wirklich gut zu beobachten, darauf zu achten, im Zweifelsfall auch mal jemand Externen mit reinholen und den mal fragen und sich mal ein Bild von jemand anders machen lassen in Form von Reviews in Form von irgendwelchen anderen Dingen. Denn manchmal ist man auch betriebsblind, das ist auch ein Klassiker. Man sieht nicht, dass man Dinge nicht so gut machen könnte oder man merkt noch nicht mal, dass das wirklich schon zäh ist.
Sven Johann: Also tatsächlich hatte ich es auch schon öfter, dass Leute einfach sagen, wir sind betriebsblind und sagen, schau mal drauf. Ich bedanke mich auf jeden Fall bei euch, auch in der Vorbereitung für den Podcast. Allein die Erkenntnis, dass es irgendwie normal ist, weil wir als Leute im Unternehmen sagen schnell: Ach bei uns ist immer alles so kompliziert und das liegt an uns. Dass wir einfach sehen, im Grunde genommen ist das einfach der normale Teil der Entwicklung. Wir dürfen es halt einfach nicht laufen lassen und es passiert auch bei den Industrie Vorreitern. Das ist eigentlich völlig normal, dass das passiert. Wir müssen halt nur darauf reagieren. Okay, das wäre mein Schlusswort. Habt ihr noch ein Schlusswort?
Jörg Müller: Ich schließe mich deinem Schlusswort an, ich fand das super.
Sven Johann: Okay, dann bedanke ich mich auf jeden Fall bei euch beiden. Ich bedanke mich bei den Zuhörern, bei den Zuhörerinnen. Happy Vereinfachung sozusagen der Komplexität. Und ja, bis zum nächsten Mal.
André Aulich: Vielen Dank.
Sven Johann: Tschüss!