Worst of Breed

This transcript was generated automatically and has not been manually reviewed. It may therefore contain errors. The spoken word in the recording is always authoritative.

Sven Johann: Hallo und herzlich willkommen zu einer neuen Folge vom INNOQ Podcast. Heute mit Tammo van Lessen zu Worst of Breed. Best of Breed ist ja Klassenbester, glaube ich. Worst of Breed das Gegenteil. Bevor wir da reingehen, vielleicht noch mal kurz was zu Tammo. Tammo ist Principal Consultant bei der INNOQ. Wir haben ja bei LinkedIn festgestellt, die automatische Übersetzung ist Chefberater. Chefberater, ja. Ganz früher mal, muss man eigentlich immer noch mal erwähnen, Buchautor und Apache oder Autor und so weiter. Aber so außer Principal, außer Chefberater, außer Chef spielen hier. Ja, was machst du so den ganzen Tag über?

Tammo van Lessen: Das mit dem Chefberater muss ich mir auf jeden Fall merken, das gefällt mir sehr gut. Ja, ich bin in verschiedenen Projekten tätig in verschiedenen Rollen. Manchmal mache ich mir die Hände noch selber schmutzig, an vielen Stellen versuche ich dafür zu sorgen, dass die Projekte gelingen.

Sven Johann: Okay, okay.

Tammo van Lessen: Was auch immer dafür zu tun ist, ja.

Sven Johann: Sehr gut. Ja, Worst of, also Best of Breed, die Leute, die Klassenbesten, die bringen eigentlich die Projekte immer zum Erfolg, aber Worst of Breed hört sich eher so an, als sei der Projekterfolg gefährdet. Was ist überhaupt Worst of Breed?

Tammo van Lessen: Ja, meinst du jetzt die Webseite oder sollen wir mal über die Definition nachdenken?

Sven Johann: Ich meinte eigentlich die Webseite, aber jetzt, wo du Definition sagst, vielleicht fangen wir mit der Definition an und dann gehen wir auf die Webseite.

Tammo van Lessen: Ja, das ist ja eng miteinander verbunden. Also wir müssen, glaube ich, wieder bei Best of Breed anfangen, weil ich bin mir nicht sicher, ob das eigentlich was anderes ist als Worst of Breed. Also es wird ja immer gerne davon geredet, dass man einfach die besten Dinge miteinander integriert. Ich kann mich noch an einen Kunden erinnern, wo es darum ging, welche Drittsoftware braucht man denn jetzt, und die sagten einfach, ja, wir kaufen einfach immer oben rechts im Gartner Quadranten. Und ja, es wird nicht automatisch immer alles gut, wenn man von allem das Beste zusammensteckt. Ich habe

Sven Johann: Mhm.

Tammo van Lessen: habe ja früher mal gerudert, dann höre ich auch wieder damit auf, aber da ist es zum Beispiel auch so, wenn man wirklich nur die physisch besten in ein Boot steckt, heißt das nicht, dass das automatisch das beste und schnellste ist.

Sven Johann: Mhm.

Tammo van Lessen: Ähnlich ist es, glaube ich, bei Software auch so, und Best of Breed ist ja die Idee, die besten Dinge zu kombinieren. Dann kommen wir vielleicht ein bisschen in die Geschichte, wie es zu dieser Webseite überhaupt kam. Früher, als ich noch am Lehrstuhl bei Frank Leimann in Stuttgart war, bin ich das erste Mal mit dem Zynismus eines Senior Developers in Kontakt gekommen. Das war ganz lustig, da war nämlich Dieter auch Doktorand, der war eigentlich schon in Rente, aber hatte viele Schlachten mit Frank, da war der WM schon geschlagen. Und wenn wir also da in diesem Oberseminar saßen und verrückte Ideen gechallenged haben, hatte der meistens einen von zwei trockenen Kommentaren parat, nämlich das braucht kein Mensch oder das haben wir schon immer so gemacht. Das hat mich irgendwie geprägt, und so sind wir oft im Biergarten abends haben wir dann oft auch über dieses Marketingmaterial mit Best of Breed geredet und was, wenn das und das Best of Breed ist, was ist denn dann bitte Worst of Breed? Und dann, ein paar Bier später, hatte ich dann diese Worst of Breed.net Domain registriert, das muss irgendwie so 2008 gewesen sein. Ja, und seitdem gammelte die dann etwas bei mir rum, da gab es mal ein WordPress Blog drauf, der aber nicht mehr als so ein Hello World Post geschafft hatte.

Sven Johann: Mhm.

Tammo van Lessen: Und ja, dieses Jahr ist es dann irgendwie passiert, da kriegt man ja immer einmal im Jahr von dem Registrar so eine E-Mail: Achtung, die Domain läuft aus, aber du musst nichts tun, die verlängert sich automatisch. Und irgendwie habe ich gedacht, entweder muss man damit jetzt mal was tun, oder ich kündige die. Ja, genau, offensichtlich habe ich inzwischen was damit getan.

Sven Johann: Genau, und wenn man, okay, jetzt rufe ich Worst of Breed auf. Und dann sehe ich allerhand lustige Dinge, also statt Best Practices sehe ich die Worst Patterns, wir gucken uns das alles noch mal gleich genauer an, die Worst Patterns und das Tech Horror Radar, what the experts say, meine absolute Lieblingsrubrik, muss ich sagen. Und natürlich das unvermeidliche Manifesto. Also da werden ganz viele schlimme Dinge gelistet, aber wie?

Tammo van Lessen: Nur schlimme Dinge.

Sven Johann: Nur, ja, nur schlimme Dinge. Aber wie kam es denn dazu, dass du gesagt hast, das mache ich jetzt, und was war sozusagen der Trigger, jetzt da wirklich Zeit zu investieren?

Tammo van Lessen: Ja, also der Trigger war, da sind verschiedene Dinge zusammengekommen. Also das eine war diese Frage, was mache ich denn jetzt eigentlich damit?

Sven Johann: Mhm.

Tammo van Lessen: Zum anderen begegnen mir halt im Projektalltag immer mal wieder so Dinger, wo mir dann, als ich diesen Begriff Worst of Breed wieder präsenter im Kopf hatte, aufgefallen ist, das fällt eigentlich ziemlich hart in diese Kategorie.

Sven Johann: Ach so. Mhm.

Tammo van Lessen: Und genau, dann habe ich mit Gemini so ein bisschen rumdiskutiert über das Thema, was könnte man denn damit machen und so, und könnte man nicht so ein Tech Radar machen? Und meine Kinder spielen im Moment viel mit so Quartettkarten, da hatte ich auch die Idee, könnte man nicht so Quartettkarten machen? So sind wir dann bei diesen Patterns gelandet. Und während ich da so rumgespielt habe, ist mir halt aufgefallen, Anti-Patterns gibt es ja viele, wir haben ja da auch so eine Seite, ich glaube, da bist du sogar Co-Autor mit.

Sven Johann: Ja, ja.

Tammo van Lessen: Mit ein paar Kollegen, und hatte dann auch so ein bisschen Sorge, dass sich das vielleicht überlappt. Und dann ist mir ein Ding aufgefallen, und zwar das zynische Satire. Also die absolute Überspitzung von diesen Themen ist eigentlich ein Geschenk bei dieser Geschichte, weil zum einen verschleiert es die tatsächlichen Beobachtungen etwas, also niemand muss sich unmittelbar jetzt angegriffen fühlen, dass wir Dinge bei Kunden beobachtet haben.

Sven Johann: Mhm.

Tammo van Lessen: Zum anderen ist es so, ich weiß nicht, ob dir das auch manchmal so ging, wenn man so diese Polit-Satiren anguckt, Heute Show oder die Anstalt oder so was, dann wünscht man sich ja manchmal, dass in der Tagesschau oder so ähnlich auf den Punkt offensiv die Missstände sozusagen anprangert, dass das aber mit dem seriösen Journalismus sozusagen, und das kann man vielleicht übertragen auf unseren professionellen Berateralltag, da spielt halt auch Politik rein und da ist es alles nicht so schwarz-weiß und da sind Kompromisse eingegangen worden und da gibt es unterschiedliche Zielstellungen.

Sven Johann: Ja.

Tammo van Lessen: So, und dem konnte ich mich aber komplett entledigen an dieser Stelle und konnte einfach nur gemein sein. Also mich hat ein Kollege angesprochen, hat gemeint, was hast du denn jetzt gegen YAML? Und ich habe gar nichts gegen YAML. Also hier geht es ja auch, also vielleicht kommen wir da noch vorbei, YAML Templating war so ein Ding.

Sven Johann: Absolut. Mhm.

Tammo van Lessen: Und trotzdem YAML Templating tut immer weh und man kann sich wahnsinnig in den Fuß schießen und deswegen gehört es da rein. Es bedeuten die Patterns, die jetzt hier drin sind, also zumindest die, die von mir kommen, dass ich das alles ablehne und fundamental Mist finde? Nein, sondern es geht schon um den Witz auch und darum, den Finger wirklich tief in die Wunde zu legen, ja?

Sven Johann: Mhm. Ja, es gibt übrigens tatsächlich so ein paar Überlappungen zu den Architecture Anti-Patterns, also so zwei von den Worst Patterns, die findet man auch bei den Anti-Patterns. Können wir jetzt drüber reden, würde ich sagen, weil ich würde einfach mal so ein paar Beispiele nehmen. Ja. Ich bin hier gerade auf der Seite Design Patterns. Und zwar, ich meine, das sind so ein, ich nehme mal so eins, das mir, wo ich mal ein Fan war, ne? Also ich lese hier mal so vor: The Nano Service Swarm. We shouldn’t just refactor the user module, let’s put the date formatter into its own container so we can scale date parsing independently, ja? Ist sozusagen so ein Ding. Ist jetzt so als, also ich meine, ist natürlich so ein Extremfall, wie du sagst, ne? Also da fühlt sich keiner angegriffen, weil es irgendwie so absurd ist, aber tatsächlich, das sieht man natürlich in the Wild. Und interessanter, was ich bei dem Pattern noch ganz interessant finde, das war ja auch was, was Adrian Cockcroft himself gepusht hat. Also. Da, also ich, als ich gelesen habe, da hat sich bei mir, habe ich so ein bisschen Schmerzen gespürt, weil ich gedacht habe, oh, in diesem Camp war ich auch mal. Ja.

Tammo van Lessen: Das stimmt. Zum Glück entwickelt man sich ja weiter oder lernt dazu, ne? Ich glaube, ich war auch mal in dem Camp tatsächlich. Und dann macht man halt die Erfahrung, ich kann mich noch erinnern, dass wir bei irgendeinem Ding mal versucht haben, diese DDD-Schnitte zu machen und die einfach zu eng waren und dann kam irgendwie die nächste Anforderung rein, die einfach beide Bounded Kontexte gebraucht hat und dann hat das halt einfach unglaublich wehgetan, dass man das so früh so getrennt hat. Ja, ich glaube, diese Erfahrung muss man machen. Übrigens, dieses Pattern ist eine der ersten Contributions, die über GitHub reinkam, natürlich irgendwie aus dem Netzwerk ein geschätzter Ex-Kollege von mir gewesen und der meinte halt, er sieht das halt bei sich gerade so, dass es total die Tendenz gibt, die Anwendung ohne Not unnötig klein zu schneiden und daraus ist halt dann dieses Pattern hier entstanden, was es natürlich überspitzt. Also ich hoffe, niemand wird den Date Formatter in einen Container stecken. Jetzt kann ich mich auch noch erinnern, dass wir ja selber argumentiert haben, dass man sozusagen, dass man den Entwicklern so wenig zutraut auf ihre Schema, nee, auf ihre Package, also ihre Package Strukturen einzuhalten, dass man sagt, wenn wir da eine Network Boundary dazwischen machen, dann müssen sie es aber halt auch tun.

Sven Johann: Mhm.

Tammo van Lessen: Ich glaube inzwischen, dass das eine blöde Idee ist, ja, genau.

Sven Johann: Ja, ja, also jedes Pattern hat ja so eine Beschreibung, ne, und die hatte ich ja gerade, also so ein Zitat. Und sagen wir mal, dann gibt es noch sozusagen so eine Analyse-Seite darüber, ne? Ist ja im Prinzip schreibst du ja auch, ne, ist im Grunde genommen die Falle, in die ich auch getappt bin, ne, die Architecture Team read a blog post about Netflix in 2014, so war es bei mir nicht. Ich habe, war ein Independent Blogpost von Adrian Cockcroft, der war, glaube ich, from Moving from Services to Functions und dann hat er im Prinzip völlig logisch hergeleitet, warum wir genau das tun werden. Dann okay, wenn der das sagt, dann werden wir genau das tun, ja.

Tammo van Lessen: Genau.

Sven Johann: Genau, dann hast du ja noch gesagt, du hast so ein bisschen Quartett spielen da drin, ja?

Tammo van Lessen: Genau, es gibt halt oben diese, also es gibt ein Icon, es gibt einen Titel, es gibt ein Tag oder eine Kategorie, es wurde auch schon angemerkt, ist aktuell noch so ein bisschen verwirrend, dass es irgendwie Kategorien und Tags gibt, also man kann über das Metamodell streiten, aber es ist ja trotzdem eine Spaßseite.

Sven Johann: Ja.

Tammo van Lessen: Dann gibt es ein passendes Icon und die Latenz, die aussagt, wenn du das machst, wird dein System so und so viel langsamer in Prozent. Auch das hat sich so ein bisschen entwickelt. Man kann es noch sehr viel lustiger anreichern, wenn man da noch Kommentare dran macht. Ich hatte zwischendurch mal Dinge, wo wir gesagt haben, das ist der Value for Business und der Value for Resume.

Sven Johann: Mhm.

Tammo van Lessen: So hat sich das aber rauskristallisiert: Latenz, Maintainability, den Schmerz und besonders den Wert für den Lebenslauf. Das kann man vielleicht noch ein bisschen sagen. Die drei Säulen oder die Ideen, die hinter dem ganzen Ding stecken, sind zum einen Resume Driven Development oder Conference Driven Development, wie wir es manchmal nennen. Der Haupttreiber

Sven Johann: Ja.

Tammo van Lessen: dafür ist, dass man mal guckt, dass man eine Technologie macht, die man entweder im Lebenslauf gebrauchen kann oder die nicht so langweilig ist, wie das, was man tagtäglich erlebt. Das passiert mir auf Konferenzen tatsächlich, dass Leute zu unserem Stand kommen und erzählen, sie haben jetzt schon zum dritten Mal ihr Frontend Framework ausgetauscht. Dann fragt man sich schon, wer hat denn jetzt was davon gehabt, außer, dass ihr eine gute Zeit hattet?

Sven Johann: Mhm.

Tammo van Lessen: Genau, und das andere ist Komplexität als Statussymbol und Cargo Culting. In dem Ding steckt halt wirklich ganz viel Cargo Culting. Wer die Skalierungsanforderungen von Netflix hat, für den mag das relevant sein, auch so eine Architektur zu machen, aber in vielen Fällen macht das wirklich gar keinen Sinn.

Sven Johann: Ja, also bei den Design Patterns ist tatsächlich die größte Nähe zu unseren Architecture Anti Patterns. Wir haben zum Beispiel auch so ein Anti Pattern Cargo Culting, ich weiß nicht, ob wir es jetzt umbenannt haben, aber dass man halt Conference Driven ist. Ich lese irgendwie Google macht, es gibt ja diesen berühmten Spruch, you are not Google, aber wen interessiert’s? Ich habe es halt gelesen, dann will ich es genauso machen. Und na ja, lassen wir es. Ex-Googler tappen wir auch immer in diese Falle. Oder was wir, glaube ich, auch haben, du hast hier den, muss ich mal hier durchscrollen, The Generic Domain Model. Wir haben ein Domain Modell für den ganzen weltweiten Konzern. Habe ich mindestens zweimal erlebt. Und wo man wirklich hart dagegen ankämpfen muss. Mittlerweile sogar dreimal. Und ja, da gibt es auf jeden Fall eine Nähe. Ich finde der Unterschied zu, also bei mir der Unterschied, so wie ich es jetzt sehe, zu den Architecture Anti Patterns ist, dass man hier einfach wild drauf los wettern kann.

Tammo van Lessen: Absolut.

Sven Johann: Bei den Anti Patterns haben wir ja schon so eine, ich sag mal, gewissermaßen eine Analyse, was war denn eigentlich die gute Idee? Weil niemand steht morgens auf und denkt sich, ich reiße jetzt die ganze Firma in den Abgrund, weil ich sage, wir haben ein Generic Domain Model. Macht einfach keiner, passiert trotzdem. Und dann ist immer die Frage, wie kommt man dahin? Das ist ja eigentlich auch das, was du gesagt hast, ganz am Anfang. In diesem ganzen Wirrwarr von individuellen Zielen, Firmenpolitik und so passieren halt schlimme Dinge. Kommen halt schlimme Dinge raus.

Tammo van Lessen: Genau, hier ist die Annahme tatsächlich anders. Hier ist die Annahme, dass es genau die Leute gibt, die das entweder mit Absicht oder aus Versehen machen und der abgehalfterte zynische Senior Developer dokumentiert das hier.

Sven Johann: Genau, genau. Ja, also ich meine, das finde ich auch, es gibt die Sachen, die ich jetzt genannt habe, da gibt es einen Overlap. Aber du hast ja so etwas wie The Trust me JWT Parser, wo Leute ihren eigenen Parser schreiben und der hat natürlich dann Sicherheitslücken. Da kann man einfach nur sagen, das ist schon ziemlich idiotisch, da kann man nichts anderes mehr sagen.

Tammo van Lessen: Das Verrückte dazu ist, dass wir das halt zweimal in Architektur Reviews gesehen haben.

Sven Johann: Mhm.

Tammo van Lessen: Man kann ja so ein Token einfach annehmen. Ich verstehe den Gedanken, dass man sagt, wir schneiden das an den Punkten auseinander, Base64 das, aber die Idee ist ja schon, dass man am Ende die Signatur, die da drin ist, prüft.

Sven Johann: Mhm.

Tammo van Lessen: Und wir hatten tatsächlich zwei Architektur Reviews, wo wir das Token einfach bearbeiten konnten, da die Rolle auf Admin setzen konnten und plötzlich weitreichendste Rechte in dem System hatten.

Sven Johann: Ach so.

Tammo van Lessen: Deswegen liest sich das so, als ob es die Kategorie ist, die sich keiner ausdenken kann. Aber es passiert eben tatsächlich. Ich muss gestehen, ich hatte sehr viel Spaß dabei, diese Seite zusammenzustellen. Ich war auch ein bisschen baff, also Gemini ist wirklich ein guter Sparringspartner, wenn es darum geht, gemein und zynisch in den Formulierungen zu sein und das auf den Punkt zu formulieren. Da habe ich mit ihm darüber diskutiert und finde, es sind sehr schöne Gems dabei herausgekommen.

Sven Johann: Ja.

Tammo van Lessen: Genau, aber sie haben alle irgendwie einen wahren Kern oder eine Beobachtung, die wir schon irgendwo gemacht haben.

Sven Johann: Ja. Ich kann auch nur empfehlen, sich das alles mal reinzuziehen. Es ist zum einen zum Totlachen, dann ist es wirklich super formuliert. Ich habe schon gedacht, der Tammo, der kann ja super formulieren, als du dann gesagt hast, na ja, das war hier mit Gemini, da habe ich okay, mit Gemini Hilfe. Und was ich mir noch gedacht habe, so zum Abschluss, gerade bei dieser Kategorie, wenn ich im Projekt wieder irgendwas Unsinniges sehe, dann kann ich natürlich sagen, hey, ich schicke mal so einen Link rum, einfach um noch mal auf die Spitze zu treiben, was sich Leute da wirklich ausdenken. Und wenn man sagt, du bist halt auf so einer Worst of Parade. Und

Tammo van Lessen: Absolut.

Sven Johann: Vielleicht kann man Leute noch umstimmen, wenn nichts mehr hilft.

Tammo van Lessen: Genau dafür ist es gedacht. Das gibt auch, vielleicht ist das noch zu versteckt. Wenn ich mir die Statistiken so angucke, werden relativ wenige von diesen Einzelseiten angeguckt. Man kann ja auf der Startseite die Karten flippen, dann kommt da auch der Permalink. Aber genau, das war schon die Idee, dass man den Permalink nimmt und irgendwie durch die Gegend schicken kann. Das ist schon ganz lustig, weil man sieht zum Beispiel in den Statistiken, dass es offensichtlich irgendwie im SharePoint eines großen deutschen Automobilherstellers gelandet ist. Ich finde, genau da gehört es vielleicht auch hin. Auch aus Teams sieht man immer wieder Dinge und auf Hacker News gab es einmal zwei Stunden Hacker News Fame. Da meinte auch einer, er wird das auf jeden Fall in seiner Hosentasche behalten und dann irgendwie in Teams werfen, immer wenn man das mal gebrauchen kann. Das ist für mich sozusagen das beste Feedback, weil das finde ich total super, wenn das klappt und funktioniert und sich so ein bisschen verbreitet und wenn natürlich weitere Einsendungen kommen.

Sven Johann: Ja, ja, also Famous Last Words, ne? Ich will, ich habe auf jeden Fall auch viele Beispiele, die ich einsenden kann, aber das habe ich auch bei Architecture Anti Patterns gesagt, ich habe viel mehr Ideen und dann kam nur, also ich habe schon was beigesteuert, so ein paar Cases, ne, aber muss auch dazu sagen, Architecture Anti Patterns ist deutlich mehr Arbeit, ne? Hier musst du dich gar nicht, kannst du dich kurz halten. Und ich denke, das gehört wirklich in die Toolbox von vielen von uns, ja? Meine Frau, die hat sich immer gefragt, was macht er eigentlich den lieben langen Tag, ne? Also weiß man ja nie so bei Leuten, die im Homeoffice sitzen und auf Bildschirme starren und dann war die mal eine Woche zu Hause, wo ich gearbeitet habe. Und die Zusammenfassung von meiner Arbeit war, Sven ist eigentlich immer nur am Telefonieren und versucht Leute davon zu überzeugen, Dinge nicht zu tun, ne? Und hier wird mein Job massiv vereinfacht, wenn man einfach nur diese Sachen durch die Gegend schicken kann, ja? Genau, also von wegen Jodpa selbst schreiben, ne, da hatten wir auch mal den, das muss ich auf jeden Fall auch einsenden. Wir hatten ja mal im Projekt jemand gehabt, dem war das Spring Framework zu komplex für das Problem, aber Pico Container war zu einfach und dann hat er einfach das Budget verbraten, um seinen eigenen Dependency Injection Framework zu bauen.

Tammo van Lessen: Kann man mal machen.

Sven Johann: Genau, genau. Okay, ich würde kurz weitergehen zu meiner Lieblingskategorie. Die ist schön kurz. What’s Experts Say? Ich nehme mal ein Beispiel, bevor wir zum Hintergrund kommen. Also What the Experts Say Reviews from the World’s Top Resume Driven Developers, da haben wir es mal wieder, ne? Unser Visionary CTO Web3 Disruptor sagt: Implementing a Blockchain to store user session data was the logical next step for our To-Do App. Decentralization is the future of Cookies. Finde ich einfach zum Weglaufen. Komisch, da gibt es auf jeden Fall noch ein paar andere und ich freue mich auch, ich freue mich auch immer, wenn da, also da brauchen wir einfach ganz viel davon. Weil ich würde mal sagen, diesen Bullshit, den höre ich, also so ein Bullshit höre ich vergleichsweise oft. Ich glaube, jedes Unternehmen hat mindestens eine Person, die, wie Gregor Hoper sagen würde, die nichts, die nicht viel zu tun hat aus Gründen, ja? Also die Firma weiß schon, warum diese Person nicht zu sehr vollgeballert ist mit Aufgaben und die laufen halt immer rum mit irgendwelchen in Anführungszeichen Innovationsthemen, ja? Und dann kommt immer irgendein Murks raus. Genau, also an alle Zuhörer und oder Zuseher, das müsst ihr euch auf jeden Fall reinziehen, ist zum Wegwerfen, ja, aber wie kamst du eigentlich da drauf? Wie kamst du auf diese Kategorie?

Tammo van Lessen: Na ja, ich hatte ja, als erstes hatte ich die Patterns oder die Idee, diese Karten zu machen und dann kam das Tech Radar dazu und dann war die Frage, was ist denn der gemeinsame Nenner, wie bauen wir denn das jetzt irgendwie zusammen? Und ja, gut, es ist naheliegend, wir sind im Consulting, das Tech Radar, was natürlich eine Anlehnung an das großartige ThoughtWorks Tech Radar ist.

Sven Johann: Mhm.

Tammo van Lessen: Was haben die denn als Dach? Und so kam die Idee, das muss irgendwie eine fiktive Beratungsfirma sein, die diese Patterns gut findet.

Sven Johann: Ach so, okay, okay.

Tammo van Lessen: Das sind quasi die Testimonials. Deswegen auch der Claim oben drüber: “We make bad Software.” Genau, das ist der Claim dieser virtuellen Firma. Das war die Idee, und damit man da halt irgendwie Testimonials hat, habe ich drei dahin gemacht. Als dieser Hacker News Dingsbums rumging, hat einer ein Bug-Ticket aufgemacht und gemeint, die Dinger wären so großartig, davon bräuchte man noch viel mehr. Und dann habe ich das halt noch mal umgebaut, dass wir da, also die waren am Anfang statisch, jetzt ist das ja so ein Band, was durchläuft. Es ist eine statische Seite, die mit Astro gepowert ist. Einer hat mich auf LinkedIn auch gefragt, wie viele Nodes der Kubernetes Cluster hätte, auf dem diese Seite läuft. Die offizielle Antwort darauf ist: Man kann sie nicht zählen. Die inoffizielle Antwort ist: Es ist eine Astro-Seite, die bei Cloudflare gehostet ist und relativ wenig Aufwand macht. Genau, und das habe ich dann so umgebaut, dass man da JSON-Files per Pull Request gerne einsenden kann, um noch ein paar mehr davon zu machen. Es gibt übrigens auch einen Tonality Guide. Ja, genau. Da ist das sozusagen beschrieben, dieser Jaded Senior Developer, der frustriert ist. Diese Persona ist da drin beschrieben und auch die Strukturen. Ich glaube, die “What’s Experts Say” – das fällt mir gerade ein – sollte man da vielleicht noch mal ergänzen, dieses JSON-Format auf jeden Fall. Wenn man einer Intelligenz diesen Tonality Guide gibt, kommt man zu ganz guten Ergebnissen, sei es, wenn man es selber tut oder wenn man sich dazu Hilfe holt.

Sven Johann: Okay, ja, ja. Ah, okay, das wusste ich gar nicht, dass du den Tonality Guide da auch hast. Ja, genau, das ist auf jeden Fall super, ja.

Tammo van Lessen: Ja, ich habe ein bisschen überlegt, wie ich das mache, wenn man das, also ich wollte das so machen, dass man Contributions annimmt und dass das nicht nur meins ist, sondern dass das nur gebootstrapped ist und sich so eine, ich weiß nicht, Community ist ein bisschen übertrieben, aber dass sich das sozusagen noch füllen kann. Und dann kommen ja so Fragen, wie kriegt man die gleiche Struktur hin, eine gewisse Ähnlichkeit, wie gehe ich mit Submissions um, bei denen ich das Gefühl habe, die passen nicht oder die gibt es schon? Und da habe ich ein bisschen drüber nachgedacht und so bin ich dazu gekommen, diesen Tonality Guide zu schreiben. Und ich habe das jetzt auch so gemacht, dass man Related Patterns machen kann. Also wenn jetzt einer irgendwie das gleiche oder den gleichen Sachverhalt noch mal wahnsinnig gut überspitzt einsendet, dann kann man die sozusagen einfach miteinander verlinken. Das muss jetzt nicht so wahnsinnig viel Wert auf Deduplizierung legen, diese Sammlung, ne?

Sven Johann: Miesy, da kommt der Chefberater durch, ja.

Tammo van Lessen: Ja, auf jeden Fall.

Sven Johann: Ja, der Stratege kommt da durch, ja. Genau, du hast schon, also ich muss noch mal wiederholen: Guckt es euch an, macht Einsendungen. Also ich stelle mir halt schon vor, ich denke einfach hier noch mal an “Thanks to Worst of Preed, we successfully migrated our 500 line PHP script to a Kubernetes cluster with 12 microservice latency increased by 4000%, but our resume value skyrocketed.” Ich hätte schon so zwei, drei Situationen beim Kunden gehabt, wo ich wirklich ernsthaft über so Sachen diskutiert habe, dass wir Dinge nicht tun, ne? Also warum, ne? Weißt du, die Motivation und eigentlich könnte man dann und hat praktisch mein Engineering Manager, der hat immer gesagt, wir machen das jetzt nicht, es sei denn jemand hat wirklich gute Argumente, um das doch zu machen, ne? Und jetzt würde ich einfach immer so ein “What the Experts Say” oder so reinwerfen und sagen: Überzeug mich, dass das, was wir hier tun, jetzt dieser überspitzte Wahnsinn ist. Okay, wir ziehen weiter zur.

Tammo van Lessen: Übrigens, wo ich das hier gerade sehe, ich habe es auch gerade aufgemacht und ich freue mich jedes Mal über das Manifesto, was unten drunter steht. Ich weiß nicht, ob du da auch noch vorbei wolltest.

Sven Johann: Ich wollte da vorbei, aber wenn du schon ein Manifesto erwähnst, dann machen wir vor dem Manifesto, vor dem Tech Radar, noch das Manifesto. Genau, man braucht immer ein Manifesto, ne?

Tammo van Lessen: Auf jeden Fall, genau, ja.

Sven Johann: Und und.

Tammo van Lessen: Und die Manifestos, die sind ja so, ich weiß nicht, ob dir das auch so geht, aber ich finde, man liest die und man denkt, ah, da hat sich jemand wahnsinnig viele Gedanken gemacht und hat einen komplexen Sachverhalt auf diese kleinen, vielleicht fünf oder zehn Aussagen, bestehend aus irgendwas über irgendwas, eingedampft. Und da ist sozusagen die ganze Weisheit aus fünf Jahren Erfahrung und Diskussion drin. Sodass ich hier immer wieder drüber stolpere, weil es einfach so falsch ist, ne? Complexity over Simplicity, Process over People, Tools over Solutions und Resume over Value. Und trotzdem, ich weiß nicht, ob dir das auch so geht, ist es halt so ein Spiegel unserer Branche, obwohl wir diese Manifestos haben und alle darauf schwören, dass sie sich daran halten wollen, landen wir doch oft immer wieder bei genau dem Gegenteil davon, oder?

Sven Johann: Genau, also als ich dieses Manifesto gelesen habe, habe ich gedacht, okay, nailed it, ja. Also vielleicht nicht immer alle vier in allen Situationen, aber ich sag mal so im Dunstkreis von so einer größeren Firma, ne? Also Complexity over Simplicity ist der Klassiker, ne? Unser ehemaliger Kollege Eberhard Wolf, der hat ja sogar mal so einen Vortrag, glaube ich, gemacht, ne, “Why we worship Complexity”, ja? Process over People, ne, der Klassiker, das können wir mit einem Tool erschlagen. Und ja. Resume over Value, klar, das ist halt das zentrale Element, ist ja Resume Driven Development, ja?

Tammo van Lessen: Genau.

Sven Johann: Ja, die Frage ist, die ich mir bei dem Manifesto gestellt habe: Wie kann ich sozusagen dieses Manifesto nutzen, um das Gegenteil zu erreichen, ja?

Tammo van Lessen: Ja, die.

Sven Johann: Ja. Was würdest du sagen? Also ich hätte eine Idee, aber sag du als erstes.

Tammo van Lessen: Ja, ich bin gespannt auf deine Idee, ich habe auch eine Idee, das ist ja vielleicht ganz anders, als was du dir vorstellst. Ich finde, da muss ein Aufkleber draus werden und ich will mir den unbedingt auf meinen Laptop kleben.

Sven Johann: Also, ich denke auch, daran habe ich nicht gedacht, so ein Aufkleber wäre ziemlich cool, ne? Aber auch hier zu dem Manifesto könnte man natürlich auch Beispiele prägen. Also zum Beispiel Architecture Anti Patterns beschreibt ja immer so ein Anti Pattern und dann gibt es Beispiele. Und du hast ja zum Beispiel bei den Design Patterns so Texte, die irgendwie irgendwelche Technologien oder Problematiken beschreiben und die kann man dahin linken. Und genauso kann ich mir halt vorstellen, hier noch mal so nach Manifesto Einträgen zu filtern, ja? Ja, also.

Tammo van Lessen: Ja, genau, das sind im Grunde die Qualitätsziele, ne? Und die Patterns zahlen darauf ein.

Sven Johann: Genau. Weil gerade, wie du sagst, ne, wie du ganz am Anfang gesagt hast, so wie die heute Show oder ich meine, die amerikanischen Late Nighter sind ja auch besonders gut darin, wenn man so wirklich überspitzt, verrückt die Sachen auf den Punkt bringt und die so reinwirft, da habe ich schon das Gefühl, dass man damit was erreichen kann, ja? Man muss natürlich irgendwie, man muss es nett verpacken, ne? Man kann jetzt nicht irgendwie so gemein so einen Link da reinwerfen, man muss schon irgendwie so, weiß ich nicht, mit Smiley, ne, erinnert mich so ein bisschen daran und muss also, dass man den Leuten nicht zu sehr auf den Schlips tritt. Aber dass man schon irgendwie die Situation mit so einem Scherz klarmacht und an was mich im Grunde genommen all das auch erinnert hat, sind die Metaphern, die man früher so kennt, also Kent Beck, also eigentlich diese ganzen Nasen, ne, Kent Beck, Gregor Hoper und so weiter, die kommen ja bei allem mit irgend so einer Metapher, ja? Und am Anfang habe ich immer gedacht, warum machen die das und dann war klar, das brennt sich halt ins Gehirn rein, ja? Und soweit wie Tools over Solutions, ne, oder Process over People, wenn man da noch mit so einem Beispiel kommt und das kombiniert, dann denke ich immer, das kriegst du nicht mehr aus dem Kopf, ne? Du hast es einmal gesehen und dann kannst du es nicht mehr, it cannot be unseen, ja?

Tammo van Lessen: Ja.

Sven Johann: Genau. Alright, ja, also Manifesto ist auf jeden Fall, ja, also wir brauchen den, wir brauchen Aufkleber und vielleicht, das wäre vielleicht auch noch eine Idee, so als Hintergrundbild. Weißt du, hast du eine Teams Session, ne, und dann fangen Leute an irgendwas zu machen, dann kannst du den, dann kannst du den Hintergrund austauschen und dann hast du dieses, hast du dieses Manifesto. Genau.

Tammo van Lessen: Sehr gut, das nehme ich mal auf, ja.

Sven Johann: Genau, genau. Ja, und hier noch mal der Aufruf, also immer wenn man irgendwelche bescheuerten Dinge sieht, sendet sie an Tammo, ne? Also muss einfach so sein, so wie Kevlin Henny kriegt ja immer alle Stack Traces zugesendet und alle verrückten Dinge gehen jetzt hier an Worst of Preed. Okay, wir gehen zum, wir gehen zum letzten Punkt, und zwar The Tech Horror Radar. Und genau, erzähl doch mal, wie ist das aufgebaut? Also klar, wir haben hier das ThoughtWorks Tech Radar of Fame, aber wie hast du das aufgebaut?

Tammo van Lessen: Ja, genau, also die Idee war tatsächlich, das einfach umzukehren, ne? Also die normalen Tech Radare, die sagen, was du nutzen sollst mit Adopt, und wir sagen hier mal, wovor du weglaufen sollst, also Burn with Fire. Und die.

Sven Johann: Aber das ThoughtWorks Tech Radar hat doch auch Hold oder so was, ne? Nutzt es nicht mehr.

Tammo van Lessen: Ja, richtig, genau, stimmt, es gibt auch Hold. Ich finde, das ist tatsächlich eine sehr interessante Kategorie, wo ich mich manchmal ein bisschen wundere. Die ist oft ziemlich leer, diese Sektion. Es wäre mal interessant, sich mit dem ThoughtWorker dazu zu unterhalten, wie sie das eigentlich kuratieren und was die Kriterien sind. Wahrscheinlich stelle ich mir vor, dass es unendlich groß wäre und deswegen sagen sie, das ist für besonders hervorstechende Dinge. Aber stimmt natürlich, hier ist es halt tatsächlich komplett umgekehrt. Das wäre so, wie wenn man hier sagen würde, na ja, ausnahmsweise darfst du das vielleicht mal nutzen, beziehungsweise die Kategorie Despair fällt vielleicht da rein. Die Idee ist von diesen Quadranten, es gibt hier vier Quadranten. Das eine ist Resume Driven Tooling, also die Dinge, die man nur für den Lebenslauf macht. Dann gibt es Zombie Technologies, also Zeug, das man einfach nicht mehr benutzen sollte, was aber irgendwie nicht weggeht. Das ergibt sich dann aus diesen konzentrischen Kreisen. Dann gibt es Cargo Cults und Theater, also Dinge, die kein echtes Problem lösen. Und dann gibt es noch Footguns und Booby Traps, also Dinge, wo man sich wahnsinnig gut in den Fuß schießen kann. Das sind die Quadranten und darin gibt es dann eben noch mal in diesen konzentrischen Kreisen verschiedene Threat Levels. Da gibt es Burned with Fire, das ist das Ding, das sollte man so schnell wie möglich versuchen, loszuwerden, weil hier steht Active Danger to Life, Health and Insanity, Remove Immediately. Das geht aber noch. Die nächste Kategorie ist dann Containment Breach, da hat es sich schon zu weit ausgebreitet, ist schon überall in der Firma und das Einzige, was wir jetzt noch machen können, ist zu isolieren, also hier die Strangler Pattern anwenden.

Sven Johann: Ah, okay, ja, ja.

Tammo van Lessen: Aber wir können es nicht mehr ausrotten. Dann Resume Only, das Feld passt nicht so ganz da rein, aber das passt halt in das Grundthema der Seite. Das wird also quasi hauptsächlich gemacht, damit man damit auf Konferenzen glänzen kann, aber in Produktion weiß ich nicht, ob man es da unbedingt einsetzen muss. Und dann gibt es halt dieses Despair. Das heißt, wir haben einfach völlig resigniert, das Ding ist halt einfach da. Und das, was sich da halt irgendwie aufhält, hier in dem Ding ist halt Lotus Notes, könnte, glaube ich, genauso gut SharePoint, SAP, solche Kandidaten sein.

Sven Johann: Ja, der Gedanke kam mir gerade so, dass wir natürlich dieses Tech Horror Radar auch in einer Firma einsetzen könnten. Ich kann mir gut vorstellen, dass viele ein Tech Radar machen, um eine Tech Strategy zu entwickeln. Aber so ein Tech Horror Radar kann man natürlich auch einsetzen, um, ich sag mal, es hat zwei Vorteile, finde ich. Zum einen kann man immer so ein bisschen Dampf ablassen, und zum anderen kann man vielleicht wirklich Dinge verbessern, weil man Druck auf Leute ausübt, die an verrückten Lösungen festhalten. Dann wäre so mein Gedanke, der ist mir gerade so gekommen: Wenn ich Resume Only rausnehme, dann haben wir zwar nur drei Kreise, aber dann passt es irgendwie. Also so Burn with Fire, Containment Breach und Despair. Und dann kann man die Sachen schön eintragen. Meine Erfahrung ist ja auch, wenn man so etwas hat, dass tendenziell Entscheider auch darauf gucken und sagen: Müssen wir vielleicht ändern? Das ist ja so mein, wenn ich beim Kunden bin, ich habe ja immer irgendwie so einen Auftrag, ich soll irgendwas machen, aber um so einen Überblick zu bekommen, rede ich auch meistens mit den Leuten, was sie besonders nervt und so weiter. Was irgendwie gut, also auch was gut läuft, was schlecht läuft, aber was sind sozusagen so Roadblocks? Und das ist natürlich auch so eine Art und Weise, in lustig solche Roadblocks zu formulieren.

Tammo van Lessen: Absolut, das ist tatsächlich die interessante Erfahrung, die ich hier auch gemacht habe. Wenn ich das so mache, das ist zwar irgendwie lustig, aber das hat schon einen Wert. Das haben wir in den News oder auf LinkedIn, das haben mir auch Leute geschrieben, dass das genau den Finger in die Wunde legt. Es ist ganz lustig, weil beim aktuellen Kunden reden wir zum Beispiel teilweise über die 1000 Nadelstiche, die immer irgendwo stören. Und das sind halt, ich glaube tatsächlich, dass so ein Radar helfen könnte. Wie bei einem echten Radar ist es vielleicht interessant, wenn Dinge auch wieder vom Radar verschwinden. Und wenn man so ein Radar macht, wo man sagt, wir versuchen diese Dinge dann mit der Zeit zu eliminieren und sichtbar zu machen, dass uns das stört. Zum Beispiel Anwendungsentwicklung in Citrix, auf der man keine Container starten kann, wir bauen aber Container-basierte Microservice-Architektur, ist irgendwie ungünstig, muss man irgendwie mal ran.

Sven Johann: Ich hörte davon. Ja.

Tammo van Lessen: Und das hier dann auf dem Radar zu platzieren und den verschiedenen Ebenen sichtbar zu machen: Hier, guck mal, das sind die Sachen, die uns wirklich wehtun. Plus, da habe ich auch drüber nachgedacht, das beißt sich halt gerade noch so ein bisschen mit meinem statischen Webseiten-Ansatz. Man könnte natürlich hier ganz schön User Feedback mit reinziehen und damit die Position der Punkte in diesen konzentrischen Kreisen beeinflussen, dass man sozusagen so ein Dot Voting oder ein Voting machen kann, die die Position bestimmt. Das wäre, glaube ich, das, was gar nicht so schlecht wäre, das in der ein oder anderen Organisation mal zu verankern.

Sven Johann: Ah ja, ja, okay. Ja, also ThoughtWorks hat ja auch praktisch „Make your bring your own Radar“, genau. Also da kann man das nutzen und entsprechend anpassen. Dann kann man doch sagen, ich will ein Dot Voting machen, das wäre bestimmt auch noch lustig. Was mir noch, was ich mir noch gedacht habe, wo du gesagt hast, die Sachen können sich dann vielleicht auch mal rausbewegen. Ein Tech-Stratege hat mal zu mir gesagt, ganz wichtig ist auch immer bei so einer Einordnung, dass man Pfeile nutzt, in welche Richtung wollen wir die Sachen eigentlich bewegen? Also vielleicht, sagen wir bei dem klassischen Tech Radar ist es so, dass wir schon sagen, wir gucken uns das an, aber wir sind der festen Überzeugung, das wird was. Also da ist die Bewegung auf jeden Fall tendenziell in Richtung Mitte. Oder da sind wir uns ein bisschen unsicher, wir gucken uns trotzdem an, tendenziell ist die Richtung eher dahin. Und hier kann man das natürlich auch machen, also ist dann immer besonders schön, wenn man sieht, wir haben hier, ich sag mal, Containment Breach und es geht halt Richtung Despair.

Tammo van Lessen: Ja.

Sven Johann: Ja. Und wenn sich dann immer noch Leute melden und sagen, wir haben hier wieder so einen Fall, wo es Richtung Despair geht, dann ist es doch wieder so, wie du sagst, es ist zwar lustig, aber da ist einfach ein sehr wertvoller und ernster Background noch dahinter.

Tammo van Lessen: Ja, genau, es hält halt schön den Spiegel vor.

Sven Johann: Ja. Alright. Genau. Ich hätte jetzt gesagt, Leute, guckt euch es an, holt, versucht es zu, lacht drüber, aber nutzt es produktiv in eurem Alltag. Schickt einfach weitere Anti-Patterns, „What the experts say“, Tech Radar Einträge, macht es einfach. Ich bin mit meinen Fragen durch. Gibt es noch von deiner Seite aus, was du noch loswerden willst, was wir auf jeden Fall wissen sollten?

Tammo van Lessen: Ja, also ich freue mich auf jeden Fall über Feedback. Mich würde interessieren, was eure Favorites sind. Sven und ich hatten vorhin im kurzen Vorgespräch auch schon ein bisschen Spaß, unsere Favorites da zu finden und auszutauschen. Ansonsten, genau, gerne Vorschläge. Das muss auch kein voller Pull Request sein, das ist natürlich nett, aber Ideen nehme ich gerne als Pull Request oder Issue in dem öffentlichen GitHub Repository oder was weiß ich was. Und wenn diese Domain leider so eine Malware-Historie hat und auf einigen Blocklisten gelandet ist, ich hoffe, ich habe sie inzwischen alle eliminiert, aber wenn ihr da noch Probleme habt, dann schreibt mir auch gerne, dann kann ich mich darum kümmern, dass die auch noch von diesen Listen verschwinden. Da bin ich dankbar über jegliche Unterstützung.

Sven Johann: Sehr gut, sehr gut.

Tammo van Lessen: Ich hoffe, dass ihr, wenn ihr euch das anguckt, genauso viel Spaß habt, wie ich hatte. Ich habe das in den Weihnachtsferien als mein Seitenprojekt gemacht und es war tatsächlich sehr lustig.

Sven Johann: Ja, also ich muss sagen, ich habe das gesehen, wurde ja auch bei INNOQ so geteilt. Und da habe ich gesagt, ah, interessant und klick auf den Link, und dann kommt halt mal wieder irgend so ein Eichhörnchen vorbeigelaufen und dann war ich wieder abgelenkt und habe es vergessen. Aber man muss es sich einfach angucken. Es ist halt, also ich denke immer so, um den Tag zu beginnen, das bräuchten wir eigentlich. Wir wissen jetzt, was wir machen müssen. Wir müssen an einem Abrisskalender arbeiten. 365 mal „What the experts say“.

Tammo van Lessen: Ja.

Sven Johann: So beginnt der Tag, oder wir sagen einfach immer, bevor der Tag beginnt, guckt euch ein Anti-Pattern an, zieht euch ein Pattern rein oder sowas.

Tammo van Lessen: Finde ich eine sehr gute Idee. Wenn wir 365 Einsendungen zusammenbekommen, es darf ja nicht alles nur AI Slop sein, das muss ja schon irgendwie ordentlich sein. Dann machen wir den Kalender.

Sven Johann: Sehr gut. Okay, dann vielen Dank an alle, die bis hierhin durchgehalten haben und danke Tammo. Ja, war schön gewesen zu sein. Und bis dann. Ciao.

Tammo van Lessen: Ja, war schön gewesen zu sein.

Sven Johann: Ebenso, ich habe wieder viele neue Ideen. Ja, ich und würde ich sagen, bis dann. Ciao.

Tammo van Lessen: Ja, ich. Ciao.

This summary was generated automatically and has not been manually reviewed. It may therefore contain errors. The spoken word in the recording is always authoritative.

Wie können Softwarearchitekt:innen und -entwickler:innen verhindern, dass „Best of Breed“-Entscheidungen in komplexe, schwer wartbare Systeme kippen? Sven Johann und Tammo van Lessen von INNOQ diskutieren mit einer ordentlichen Portion Satire, wie „Worst of Breed“ als Spiegel der Branche dient – und warum überspitzte Worst Patterns helfen können, fragwürdige Architekturtrends frühzeitig zu erkennen und zu hinterfragen.

Worst of Breed: Satire als Architektur-Review

Ausgangspunkt der Episode ist die provokante Umkehrung des bekannten „Best of Breed“-Prinzips. Tammo van Lessen beschreibt, wie aus der Beobachtung realer Projektentscheidungen die Idee zu Worst of Breed entstand – einer satirischen Sammlung von Architektur- und Technologieentscheidungen, die zwar modern und beeindruckend wirken, aber oft mehr dem Lebenslauf als dem Projekterfolg dienen.

Anstatt nüchterne Anti-Patterns zu dokumentieren, setzt Worst of Breed bewusst auf Überzeichnung. Nano-Service-Swarms, Resume Driven Development oder Cargo Culting werden so zugespitzt, dass ihre Absurdität sichtbar wird – ohne einzelne Personen an den Pranger zu stellen.

„Es geht schon um den Witz auch und darum, den Finger wirklich tief in die Wunde zu legen.“

Worst Patterns und Resume Driven Development

Ein zentrales Motiv der Diskussion ist das Phänomen des „Resume Driven Development“: Technologieentscheidungen, die weniger aus fachlicher Notwendigkeit entstehen, sondern aus dem Wunsch heraus, moderne Begriffe im Lebenslauf oder auf Konferenzen präsentieren zu können.

Sven Johann und Tammo van Lessen greifen Beispiele wie übertriebene Microservice-Zerlegungen, generische Domain-Modelle oder selbstgeschriebene Security-Komponenten auf – alles reale Beobachtungen aus Architektur-Reviews. Die satirische Darstellung schafft dabei eine Distanz, die es ermöglicht, Missstände klarer zu benennen als es im Projektalltag oft möglich ist.

“Complexity over Simplicity, Process over People, Tools over Solutions und Resume over Value.”

Das Tech Horror Radar als Werkzeug

Neben den Worst Patterns spielt das „Tech Horror Radar“ eine zentrale Rolle. Als ironische Umkehrung klassischer Tech Radars kategorisiert es Technologien und Praktiken nach Gefährdungsgrad – von „Burn with Fire“ über „Containment Breach“ bis hin zu „Despair“.

Was zunächst wie reiner Humor wirkt, kann im Projektkontext produktiv genutzt werden: als Gesprächsanstoß, als Ventil für Frustration oder als visuelles Instrument, um technische Schulden und problematische Entscheidungen sichtbar zu machen. Gerade die Überzeichnung ermöglicht es, schwierige Themen mit einem Augenzwinkern anzusprechen.

Spiegel der Branche – und Einladung zur Reflexion

Das „Worst of Breed Manifesto“ bringt die satirische Grundhaltung auf den Punkt. Aussagen wie „Complexity over Simplicity“ oder „Resume over Value“ wirken bewusst provokant – und treffen dennoch einen Nerv.

Die Episode zeigt: Satire ist kein Selbstzweck, sondern ein Mittel zur Reflexion. Indem überspitzte Muster sichtbar gemacht werden, entsteht Raum für Diskussion, Selbstkritik und bessere Entscheidungen. Worst of Breed versteht sich dabei nicht als Abrechnung, sondern als Einladung, genauer hinzusehen – und Architektur nicht zum Selbstzweck werden zu lassen.