Engineering Kiosk

#223 Throw redundancy at the tail: Request Hedging bei Google & Co.

Kennst du das? Neun Klicks sind blitzschnell, der zehnte hängt gefühlt ewig. Genau da frisst die Tail Latency deine User Experience und der Durchschnittswert hilft dir kein bisschen. In dieser Episode tauchen wir in Request Hedging ein, also das bewusste Duplizieren von Requests, um P99 zu drücken und Ausreißer zu entschärfen. Wir starten mit einem kurzen Recap zu Resilience Engineering: Timeouts, Retries, Exponential Backoff, Jitter, Circuit Breaker. Danach gehen wir tief rein ins Hedging: Was ist der Hedge Threshold, warum optimieren wir auf Tail statt Head Latency und wie Perzentile wie P50, P95 und P99 die Sicht auf Performance verändern. Wir zeigen, wie du Hedging sicher umsetzt, ohne dein Backend zu überlasten, wo Idempotenz Pflicht ist und warum Schreibzugriffe besonders heikel sind. In der Praxis klären wir, wie du Requests sauber cancelst: HTTP 1.1 via FIN und Reset, HTTP 2 mit RESET_STREAM, gRPC Support und wie Go mit Context Cancellation nativ hilft. Zum Tooling gibt es echte Beispiele: Envoy als Cloud-native Proxy mit Hedging, gRPC, Open Source Erfahrungen. In der Datenbankwelt sprechen wir über Read Hedging, Quorum Reads und Write-Constraints bei Cassandra und Kafka, über Vitess im MySQL-Universum und Grenzen von PG Bouncer. Auch Caches wie Redis und Memcached sowie DNS Patterns wie Happy Eyeballs sind am Start. Historisch ordnen wir das Ganze mit The Tail at Scale von Jeff Dean ein und schauen, wie Google, Netflix, Uber, LinkedIn oder Cloudflare Hedging verwenden. Am Ende nimmst du klare Best Practices mit: Hedging gezielt auf Tail Latency einsetzen, Requests wirklich canceln, Idempotenz sicherstellen, dynamische Thresholds mit Observability füttern und deine Guardrails definieren. Neugierig, ob Hedging dein P99 rettet, ohne dich selbst zu ddosen? Genau darum geht es. Bonus: Hedgehog hat damit nichts zu tun, auch wenn der Name dazu verführt. Keywords: Resilience Engineering, Request Hedging, Tail Latency, P99, Perzentile, Microservices, HTTP 2, gRPC, Go Context, Observability, Monitoring, Prometheus, Grafana, Envoy, Open Source, Cassandra, Kafka, Vitess, Redis, Memcached, Quorum Reads, Tech Community, Networking. Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partners [https://engineeringkiosk.dev/partners] Das schnelle Feedback zur Episode: 👍 (top) [https://api.openpodcast.dev/feedback/223/upvote] 👎 (geht so) [https://api.openpodcast.dev/feedback/223/downvote] ANREGUNGEN, GEDANKEN, THEMEN UND WÜNSCHE Dein Feedback zählt! Erreiche uns über einen der folgenden Kanäle … * EngKiosk Community: https://engineeringkiosk.dev/join-discord [https://engineeringkiosk.dev/join-discord]  * LinkedIn: https://www.linkedin.com/company/engineering-kiosk/ [https://www.linkedin.com/company/engineering-kiosk/] * Email: stehtisch@engineeringkiosk.dev [stehtisch@engineeringkiosk.dev] * Mastodon: https://podcasts.social/@engkiosk [https://podcasts.social/@engkiosk] * Bluesky: https://bsky.app/profile/engineeringkiosk.bsky.social [https://bsky.app/profile/engineeringkiosk.bsky.social] * Instagram: https://www.instagram.com/engineeringkiosk/ [https://www.instagram.com/engineeringkiosk/] UNTERSTÜTZE DEN ENGINEERING KIOSK Wenn du uns etwas Gutes tun möchtest … Kaffee schmeckt uns immer  * Buy us a coffee: https://engineeringkiosk.dev/kaffee [https://engineeringkiosk.dev/kaffee] LINKS * Engineering Kiosk #204 Resilience Engineering: Timeouts, Jitter, Backoff & andere Systemretter: https://engineeringkiosk.dev/podcast/episode/204-resilience-engineering-timeouts-jitter-backoff-andere-systemretter/ [https://engineeringkiosk.dev/podcast/episode/204-resilience-engineering-timeouts-jitter-backoff-andere-systemretter/] * Vitess Tablet throttler: https://vitess.io/docs/archive/15.0/reference/features/tablet-throttler/ [https://vitess.io/docs/archive/15.0/reference/features/tablet-throttler/] * envoy Request Hedging: https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/http/http_routing#request-hedging [https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/http/http_routing#request-hedging] * gRPC Request Hedging: https://grpc.io/docs/guides/request-hedging/ [https://grpc.io/docs/guides/request-hedging/] * The tail at Scale: https://research.google/pubs/the-tail-at-scale/ [https://research.google/pubs/the-tail-at-scale/] SPRUNGMARKEN (00:00:00) Resilience Engineering: Request Hedging (00:04:16) Recap: Resilience Engineering mit Timeouts, Backoff und Jitter (00:06:22) Was ist Request Hedging? (00:07:28) Info/Werbung (00:08:28) Was ist Request Hedging? (00:18:17) Ist Request Hedging nicht kontraproduktiv? (00:26:17) HTTP Request Cancellation (00:37:06) Dynamischer Hedge-Threshold (00:45:27) Die Arten von Request Hedging (00:48:24) Request Hedging in der Praxis und Open Source (00:57:47) Woher kommt Request Hedging? HOSTS * Wolfgang Gassler (https://gassler.dev [https://gassler.dev])  * Andy Grunwald (https://andygrunwald.com/ [https://andygrunwald.com/]) COMMUNITY Diskutiere mit uns und vielen anderen Tech-Spezialist⋅innen in unserer Engineering Kiosk Community unter https://engineeringkiosk.dev/join-discord [https://engineeringkiosk.dev/join-discord]

#222 SOLID in Go, JS & Co: passt das noch zur modernen Software?

SOLID: Single-Responsibility, Open-Closed, Liskovsche Substitution, Interface-Segregation und Dependency-Inversion SOLID klingt nach Fels in der Brandung, fühlt sich in der Praxis aber oft nach Abstraktionspyramide an. Brauchen wir die fünf Prinzipien heute noch oder bremsen sie uns beim Time-to-Market aus? In dieser Episode gehen wir genau dieser Frage nach und nehmen dich mit von der nicht ganz offiziellen SOLID-Entstehungsgeschichte über die wichtigsten Prinzipien bis hin zur ehrlichen Einordnung zwischen Clean Code, Teamrealität und AI-Overengineering. Wir starten mit dem S wie Single Responsibility und zerlegen den klassischen UserService: Was gehört rein, was raus, warum Utils-„Mülleimer“ gefährlich sind und wieso Komposition in der Praxis oft die bessere Wahl ist. Danach das O wie Open-Closed mit zwei greifbaren Beispielen: Rabattlogik ohne if-Hölle und Zahlungsanbieter-Design zwischen Switch Case und Strategie. Beim L wie Liskov Substitution wird es historisch und konkret: Barbara Liskov, Turing Award, Rechteck–Quadrat und die Frage, warum protected so oft Kapselung sprengt. Beim I wie Interface Segregation feiern wir kleine, fokussierte Interfaces, Duck Typing und die Go-Philosophie. Und beim D wie Dependency Inversion klären wir den Unterschied zu Dependency Injection, zeigen Injection-Varianten und warum Tests dadurch so viel leichter werden. Wir ordnen ein, wo SOLID glänzt und wo es Grenzen hat: Overengineering durch zu viele Klassen, DI-Container-Magic, ORMs, Microservices als Fehlinterpretation von SRP sowie der gesunde Trade-off zwischen sauberen Contracts und schneller Lieferung. Dazu Teamkultur statt Dogmatismus, Clean Code ohne Religion und die Erkenntnis, dass gute Architektur vor allem durch Datenflüsse, Domain-Zuschnitte und klare Systemgrenzen entsteht. Am Ende bleibt ein pragmatisches Playbook: Komposition über Vererbung, kleine Interfaces, klare Contracts, Injection wo es hilft und bewusstes Brechen von Regeln, wenn der Kontext es fordert. Bonus: Side Project-Idee aus der Community-Ecke. Baue einen Fax-zu-Discord-Bot. Wir integrieren ihn. Versprochen. Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partners [https://engineeringkiosk.dev/partners] Das schnelle Feedback zur Episode: 👍 (top) [https://api.openpodcast.dev/feedback/222/upvote] 👎 (geht so) [https://api.openpodcast.dev/feedback/222/downvote] ANREGUNGEN, GEDANKEN, THEMEN UND WÜNSCHE Dein Feedback zählt! Erreiche uns über einen der folgenden Kanäle … * EngKiosk Community: https://engineeringkiosk.dev/join-discord [https://engineeringkiosk.dev/join-discord]  * LinkedIn: https://www.linkedin.com/company/engineering-kiosk/ [https://www.linkedin.com/company/engineering-kiosk/] * Email: stehtisch@engineeringkiosk.dev [stehtisch@engineeringkiosk.dev] * Mastodon: https://podcasts.social/@engkiosk [https://podcasts.social/@engkiosk] * Bluesky: https://bsky.app/profile/engineeringkiosk.bsky.social [https://bsky.app/profile/engineeringkiosk.bsky.social] * Instagram: https://www.instagram.com/engineeringkiosk/ [https://www.instagram.com/engineeringkiosk/] UNTERSTÜTZE DEN ENGINEERING KIOSK Wenn du uns etwas Gutes tun möchtest … Kaffee schmeckt uns immer  * Buy us a coffee: https://engineeringkiosk.dev/kaffee [https://engineeringkiosk.dev/kaffee] LINKS * Engineering Kiosk Episode #112 Das Engineering Manager Pendulum: Zwischen Coding und Leadership mit Tom Bartel: https://engineeringkiosk.dev/podcast/episode/112-das-engineering-manager-pendulum-zwischen-coding-und-leadership-mit-tom-bartel/ [https://engineeringkiosk.dev/podcast/episode/112-das-engineering-manager-pendulum-zwischen-coding-und-leadership-mit-tom-bartel/] * Engineering Kiosk Episode #93 Barbara Liskov - Das L in SOLID (Liskovsches Substitutionsprinzip & Abstraktion): https://engineeringkiosk.dev/podcast/episode/93-barbara-liskov-das-l-in-solid-liskovsches-substitutionsprinzip-abstraktion/ [https://engineeringkiosk.dev/podcast/episode/93-barbara-liskov-das-l-in-solid-liskovsches-substitutionsprinzip-abstraktion/] * Engineering Kiosk Episode #65 Clean Code macht Software langsam: https://engineeringkiosk.dev/podcast/episode/65-clean-code-macht-software-langsam/ [https://engineeringkiosk.dev/podcast/episode/65-clean-code-macht-software-langsam/] * Traits: https://de.wikipedia.org/wiki/Trait_(Programmierung) [https://de.wikipedia.org/wiki/Trait_(Programmierung)] * Urlaub im Userspace: E011 – 30 Jahre MySQL mit Wolfi https://user.space/e011-30-jahre-mysql/ [https://user.space/e011-30-jahre-mysql/]  SPRUNGMARKEN (00:00:00) Die Geschichte zu den SOLID Prinzipien (00:06:58) Info/Werbung (00:07:58) Die Geschichte zu den SOLID Prinzipien (00:28:01) SOLID: Open-Closed Principle (OCP) (00:38:57) SOLID: Liskov Substitution Principle (LSP) (00:47:57) SOLID: Interface Segregation Principle (ISP) (00:54:16) SOLID: Dependency Inversion Principle (DIP) (01:04:18) Kritik an SOLID (01:11:09) Automatische Anwendung von SOLID durch AI? HOSTS * Wolfgang Gassler (https://gassler.dev [https://gassler.dev])  * Andy Grunwald (https://andygrunwald.com/ [https://andygrunwald.com/]) COMMUNITY Diskutiere mit uns und vielen anderen Tech-Spezialist⋅innen in unserer Engineering Kiosk Community unter https://engineeringkiosk.dev/join-discord [https://engineeringkiosk.dev/join-discord]

#221 Mobile Game Entwicklung mit Fabi Fink von Lotum

Wie baust du Mobile Games, die nicht nur Spaß machen, sondern auch auf jeder Plattform funktionieren und sich selbst tragen? In dieser Episode sprechen wir über Mobile Gaming: von der Idee über den Game Loop bis zur Monetarisierung. Mit dabei ist Fabi Fink, Game Lead bei Lotum. Lotum steht für Social Casual und Puzzle Hits wie Quiz Planet und Word Blitz, hat die Marke von 1 Milliarde Installationen geknackt und spielt technisch die gesamte Klaviatur von Web bis Native. Wir klären, warum Mobile inzwischen rund die Hälfte des Gaming-Umsatzes ausmacht und ordnen Hypercasual, Casual, Midcore und Hardcore mit vielen Beispielen ein. Wir zeigen, was Mobile heute bedeutet: Native Apps in App Store und Play Store, aber auch Games als Facebook Instant Games sowie Integrationen für Reddit, Discord, TikTok und Netflix. Du erfährst, wie Social Loops auf Plattformen funktionieren, warum asynchrones Multiplayer ein Growth-Hebel ist und was Viralität gegenüber klassischer User Acquisition auszeichnet. Technisch gehen wir tief rein: Warum Lotum für viele Titel auf Vue.js setzt und Game-UX wie eine hochinteraktive Web-App denkt. Wir sprechen über Performance-Details, GPU-freundliche Animationen und warum beim WordBlitz-Core Plain JavaScript die Nase vorn hat. Im Backend wird es handfest mit WebSockets, Redis-Clustern und Realtime-Events in der Google Cloud. Dazu kommen Tools und Plattformen wie Nakama (Open Source Backend for Games) und SpacetimeDB, plus eine ehrliche Kostenstory rund um Firebase. Natürlich geht es auch ums Geld: Ads vs. In-App Purchases, Hybrid-Modelle, ROAS über 180 Tage und was erfolgreiche Titel wirklich auszeichnet. Wir teilen KPI-Realität, A/B-Testing-Erkenntnisse, warum kleine UX-Texte große Effekte haben können und welche Schwelle ein Spiel bei Lotum erreichen sollte, um weiterverfolgt zu werden. Wenn du wissen willst, wie moderne Mobile Games entstehen – technologisch, produktseitig und monetär – schnapp dir diese Episode. Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partners [https://engineeringkiosk.dev/partners] Das schnelle Feedback zur Episode: 👍 (top) [https://api.openpodcast.dev/feedback/221/upvote] 👎 (geht so) [https://api.openpodcast.dev/feedback/221/downvote] ANREGUNGEN, GEDANKEN, THEMEN UND WÜNSCHE Dein Feedback zählt! Erreiche uns über einen der folgenden Kanäle … * EngKiosk Community: https://engineeringkiosk.dev/join-discord [https://engineeringkiosk.dev/join-discord]  * LinkedIn: https://www.linkedin.com/company/engineering-kiosk/ [https://www.linkedin.com/company/engineering-kiosk/] * Email: stehtisch@engineeringkiosk.dev [stehtisch@engineeringkiosk.dev] * Mastodon: https://podcasts.social/@engkiosk [https://podcasts.social/@engkiosk] * Bluesky: https://bsky.app/profile/engineeringkiosk.bsky.social [https://bsky.app/profile/engineeringkiosk.bsky.social] * Instagram: https://www.instagram.com/engineeringkiosk/ [https://www.instagram.com/engineeringkiosk/] UNTERSTÜTZE DEN ENGINEERING KIOSK Wenn du uns etwas Gutes tun möchtest … Kaffee schmeckt uns immer  * Buy us a coffee: https://engineeringkiosk.dev/kaffee [https://engineeringkiosk.dev/kaffee] LINKS * Lotum: https://lotum.com/de [https://lotum.com/de] * Fabi Fink auf LinkedIn: https://www.linkedin.com/in/fabian-fink-b1a606132/ [https://www.linkedin.com/in/fabian-fink-b1a606132/] * programmier.bar: https://www.programmier.bar/ [https://www.programmier.bar/] * Engineering Kiosk Episode #188 Spieleentwicklung: Die Königsdisziplin der Informatik mit Dominic Pacher: https://engineeringkiosk.dev/podcast/episode/188-spieleentwicklung-die-k%C3%B6nigsdisziplin-der-informatik-mit-dominic-pacher/ [https://engineeringkiosk.dev/podcast/episode/188-spieleentwicklung-die-k%C3%B6nigsdisziplin-der-informatik-mit-dominic-pacher/] * PixiJS - The HTML5 Creation Engine: https://pixijs.com/ [https://pixijs.com/] * Vue.js: https://vuejs.org/ [https://vuejs.org/] * SpacetimeDB: https://spacetimedb.com/ [https://spacetimedb.com/] * Nakama: https://heroiclabs.com/nakama/ [https://heroiclabs.com/nakama/] * Firebase: https://firebase.google.com/ [https://firebase.google.com/] * Google AdMob: https://admob.google.com/intl/de/home/ [https://admob.google.com/intl/de/home/] * ROAS (Return on Advertising Spend): https://omr.com/de/daily/glossary/roas-return-on-advertising-spend [https://omr.com/de/daily/glossary/roas-return-on-advertising-spend] * Pick of the Day * Fabi Fink - AINews Smok: https://news.smol.ai/ [https://news.smol.ai/] * Andy Grunwald - Spiele für Softwareentwickler:innen - https://engineeringkiosk.dev/spiele-fuer-softwareentwickler/ [https://engineeringkiosk.dev/spiele-fuer-softwareentwickler/] * Wolfi Gassler: https://www.jetzt.at/ [https://www.jetzt.at/] SPRUNGMARKEN (00:00:00) Entwicklung von Mobile Games mit Fabi Fink (00:07:26) Info/Werbung (00:08:26) Unterschiede zur klassischen und der Mobile-Gaming-Welt (00:15:48) Was kann eigentlich als Mobile Game bezeichnet werden? (00:24:03) Frontend: Wie nah sind klassische Mobile Games an der Webentwicklung dran? (00:33:00) Backend: Multiplayer und State-Management (00:41:47) Daseinsberechtigungen von Plattformen und spezielle Gaming-Backends (00:52:39) Monetarisierung von Mobile Games (01:04:39) A/B-Testing und Datenanalyse (01:09:01) Empfehlungen für neue Spiele-Entwickler*innen (01:11:47) Pick of the Day HOSTS * Wolfgang Gassler (https://gassler.dev [https://gassler.dev])  * Andy Grunwald (https://andygrunwald.com/ [https://andygrunwald.com/]) COMMUNITY Diskutiere mit uns und vielen anderen Tech-Spezialist⋅innen in unserer Engineering Kiosk Community unter https://engineeringkiosk.dev/join-discord [https://engineeringkiosk.dev/join-discord]

#220 Code Reviews als Kommunikationsnetzwerk mit Prof. Michael Dorner

Blockiert dein Code Review gerade mal wieder den Release oder ist es der unsichtbare Klebstoff, der Wissen im Team verteilt? In dieser Episode gehen wir der Frage auf den Grund, warum Reviews weit mehr sind als ein einfaches “looks good to me” und was sie mit sozialer Interaktion, Teamdynamik und Wissensverteilung zu tun haben. Wir sprechen mit Prof. Michael Dorner, Professor für Software Engineering an der TH Nürnberg, der seit Jahren zur Rolle von Code Reviews in der Softwareentwicklung forscht: mit Code Review Daten von Microsoft, Spotify oder trivago. Überall zeigt sich: Pull Requests sind mehr als technische Checks, sie sind Kommunikationsnetzwerke. Gemeinsam beleuchten wir, warum Tooling oft zweitrangig ist, wie sich Review-Praktiken historisch entwickelt haben und was das alles mit Ownership, Architektur und sogar Steuern zu tun hat. Ein Blick auf Code Reviews, der dir definitiv eine neue Perspektive eröffnet. Bonus: Wir erklären, warum alle Informatiker Doktoren auch Philosophen sind ;) Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partners [https://engineeringkiosk.dev/partners] Das schnelle Feedback zur Episode: 👍 (top) [https://api.openpodcast.dev/feedback/220/upvote] 👎 (geht so) [https://api.openpodcast.dev/feedback/220/downvote] ANREGUNGEN, GEDANKEN, THEMEN UND WÜNSCHE Dein Feedback zählt! Erreiche uns über einen der folgenden Kanäle … * EngKiosk Community: https://engineeringkiosk.dev/join-discord [https://engineeringkiosk.dev/join-discord]  * LinkedIn: https://www.linkedin.com/company/engineering-kiosk/ [https://www.linkedin.com/company/engineering-kiosk/] * Email: stehtisch@engineeringkiosk.dev [stehtisch@engineeringkiosk.dev] * Mastodon: https://podcasts.social/@engkiosk [https://podcasts.social/@engkiosk] * Bluesky: https://bsky.app/profile/engineeringkiosk.bsky.social [https://bsky.app/profile/engineeringkiosk.bsky.social] * Instagram: https://www.instagram.com/engineeringkiosk/ [https://www.instagram.com/engineeringkiosk/] UNTERSTÜTZE DEN ENGINEERING KIOSK Wenn du uns etwas Gutes tun möchtest … Kaffee schmeckt uns immer  * Buy us a coffee: https://engineeringkiosk.dev/kaffee [https://engineeringkiosk.dev/kaffee] LINKS * Website von Michael Dorner: https://www.michaeldorner.de/ [https://www.michaeldorner.de/] * Veröffentlichungen von Michael Dorner: https://scholar.google.de/citations?user=pxjtc20AAAAJ&hl=de&oi=ao [https://scholar.google.de/citations?hl=de&oi=ao&user=pxjtc20AAAAJ] * Dr. Arbeit von Michael Dorner “Code Review as a Communication Network”: https://bth.diva-portal.org/smash/get/diva2:1991183/FULLTEXT02.pdf [https://bth.diva-portal.org/smash/get/diva2:1991183/FULLTEXT02.pdf] * Inner Source: https://de.wikipedia.org/wiki/Inner_Source [https://de.wikipedia.org/wiki/Inner_Source] * AI slop attacks on the curl project: https://daniel.haxx.se/blog/2025/08/18/ai-slop-attacks-on-the-curl-project/ [https://daniel.haxx.se/blog/2025/08/18/ai-slop-attacks-on-the-curl-project/] * Tax Compliance in Software Engineering: The 30-Billion-Dollar Software Engineering Problem: https://www.michaeldorner.de/posts/the-microsoft-case/ [https://www.michaeldorner.de/posts/the-microsoft-case/]  SPRUNGMARKEN (00:00:00) Code-Reviews als Kommunikationsnetzwerk mit Prof. Michael Dorner  (00:05:37) Was ist eigentlich ein Code-Review? Und woher kommt es? Welche Informationen werden dabei ausgetauscht? (00:06:02) Info/Werbung (00:07:02) Was ist eigentlich ein Code-Review? Und woher kommt es? Welche Informationen werden dabei ausgetauscht? (00:33:23) Das Kommunikationsnetzwerk von Code-Reviews sowie die Wirtschaftlichkeit (00:41:59) Unterschiede von Code-Reviews in Open Source und in Unternehmen (00:49:17) Was wird bei einem Code-Review eigentlich überprüft? (00:56:33) Kann künstliche Intelligenz bei Code-Reviews helfen? (01:05:10) Versteuerung von geografisch verteilten Code-Reviews bzw. Software-Teams (01:13:34) Rotwein, Dr.-Arbeit und Learnings aus der Code-Review-Forschung HOSTS * Wolfgang Gassler (https://gassler.dev [https://gassler.dev])  * Andy Grunwald (https://andygrunwald.com/ [https://andygrunwald.com/]) COMMUNITY Diskutiere mit uns und vielen anderen Tech-Spezialist⋅innen in unserer Engineering Kiosk Community unter https://engineeringkiosk.dev/join-discord [https://engineeringkiosk.dev/join-discord]

#219 Technische Schulden: Bewusst aufbauen, gezielt abbauen

Technische Schulden: Code veröffentlichen und weiterziehen oder doch erst aufräumen? Technische Schulden fühlen sich oft nach Ballast an, können aber dein stärkster Hebel für Speed sein. Der Knackpunkt ist, sie bewusst und sichtbar einzugehen und konsequent wieder abzubauen. In dieser Episode sprechen wir darüber, wie wir technische Schulden strategisch nutzen, ohne uns langfristig festzufahren. Ward Cunningham sagt: Technische Schulden sind nicht automatisch schlechter Code. Wir ordnen ein, was wirklich als “Debt” zählt und warum Provisorien oft länger leben als geplant. Dann erweitern wir die Perspektive von der Code‑ und Architektur‑Ebene auf People und Prozesse: Knowledge Silos, fehlendes Code Review und organisatorische Entscheidungen können genauso Schulden sein wie ein any in TypeScript. Wir diskutieren sinnvolle Indikatoren wie DORA Metriken, zyklomatische Komplexität und den CRAP Index, aber auch ihre Grenzen. Warum Trends über Releases hilfreicher sind als Einzelwerte oder wie Teamskalierung die Kennzahlen beeinflusst. Dazu die Business Seite: reale Kosten, Produktivitätsverluste, Frust im Team und Fluktuation. Als Anschauung dient der Sonos App Rewrite als teures Lehrstück für akkumulierte Schulden. Wenn du wissen willst, wie du in deinem Team Technical Debt als Werkzeug nutzt, Metriken und Kultur klug kombinierst und den Business Impact sauber argumentierst, dann ist diese Episode für dich. Bonus: Wir verraten, warum Legacy allein keine Schuld ist und wie Open Source, Plattformteams und Standardisierung dir echte Zinsen sparen können. Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partners [https://engineeringkiosk.dev/partners] Das schnelle Feedback zur Episode: 👍 (top) [https://api.openpodcast.dev/feedback/219/upvote] 👎 (geht so) [https://api.openpodcast.dev/feedback/219/downvote] ANREGUNGEN, GEDANKEN, THEMEN UND WÜNSCHE Dein Feedback zählt! Erreiche uns über einen der folgenden Kanäle … * EngKiosk Community: https://engineeringkiosk.dev/join-discord [https://engineeringkiosk.dev/join-discord]  * LinkedIn: https://www.linkedin.com/company/engineering-kiosk/ [https://www.linkedin.com/company/engineering-kiosk/] * Email: stehtisch@engineeringkiosk.dev [stehtisch@engineeringkiosk.dev] * Mastodon: https://podcasts.social/@engkiosk [https://podcasts.social/@engkiosk] * Bluesky: https://bsky.app/profile/engineeringkiosk.bsky.social [https://bsky.app/profile/engineeringkiosk.bsky.social] * Instagram: https://www.instagram.com/engineeringkiosk/ [https://www.instagram.com/engineeringkiosk/] UNTERSTÜTZE DEN ENGINEERING KIOSK Wenn du uns etwas Gutes tun möchtest … Kaffee schmeckt uns immer  * Buy us a coffee: https://engineeringkiosk.dev/kaffee [https://engineeringkiosk.dev/kaffee] LINKS * The Invisible $1.52 Trillion Problem: Clunky Old Software: https://www.wsj.com/tech/personal-tech/the-invisible-1-52-trillion-problem-clunky-old-software-f5cbba27 [https://www.wsj.com/tech/personal-tech/the-invisible-1-52-trillion-problem-clunky-old-software-f5cbba27] * Engineers Spend 33% of Their Time Dealing with Technical Debt: https://hackernoon.com/engineers-spend-33percent-of-their-time-dealing-with-technical-debt-ze1p3wft [https://hackernoon.com/engineers-spend-33percent-of-their-time-dealing-with-technical-debt-ze1p3wft] * Measuring And Managing Technical Debt: https://www.forbes.com/councils/forbestechcouncil/2022/08/10/measuring-and-managing-technical-debt/ [https://www.forbes.com/councils/forbestechcouncil/2022/08/10/measuring-and-managing-technical-debt/] * Code Red: The Business Impact of Code Quality -- A Quantitative Study of 39 Proprietary Production Codebases: https://arxiv.org/abs/2203.04374 [https://arxiv.org/abs/2203.04374] * Paying down tech debt: https://newsletter.pragmaticengineer.com/p/paying-down-tech-debt [https://newsletter.pragmaticengineer.com/p/paying-down-tech-debt] * The hidden costs of technical debt: https://divagatio.substack.com/p/the-hidden-costs-of-technical-debt [https://divagatio.substack.com/p/the-hidden-costs-of-technical-debt] * Business costs of technical debt: https://codescene.com/hubfs/calculate-business-costs-of-technical-debt.pdf [https://codescene.com/hubfs/calculate-business-costs-of-technical-debt.pdf] * This Code is CRAP: https://testing.googleblog.com/2011/02/this-code-is-crap.html [https://testing.googleblog.com/2011/02/this-code-is-crap.html] * Sonos workers shed light on why the app update went so horribly: https://arstechnica.com/gadgets/2024/09/it-was-the-wrong-decision-employees-discuss-sonos-rushed-app-debacle/ [https://arstechnica.com/gadgets/2024/09/it-was-the-wrong-decision-employees-discuss-sonos-rushed-app-debacle/] * Things You Should Never Do, Part I: https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/ [https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/] * ISO/IEC 25010: https://iso25000.com/index.php/en/iso-25000-standards/iso-25010 [https://iso25000.com/index.php/en/iso-25000-standards/iso-25010] SPRUNGMARKEN (00:00:00) Technische Schulden als strategisches Werkzeug (00:05:13) Info/Werbung (00:06:13) Technische Schulden als strategisches Werkzeug (00:15:30) Wie entdecke ich technische Schulden? (00:23:44) Keine technischen Schulden und Legacy-Code (00:33:04) Technische Schulden werden vom Team getragen (00:37:23) Abbau von technischen Schulden und SLOs (00:51:27) Der Impact von AI auf deine technische Schulden (00:55:23) Technische Schulden von vornherein verhindern HOSTS * Wolfgang Gassler (https://gassler.dev [https://gassler.dev])  * Andy Grunwald (https://andygrunwald.com/ [https://andygrunwald.com/]) COMMUNITY Diskutiere mit uns und vielen anderen Tech-Spezialist⋅innen in unserer Engineering Kiosk Community unter https://engineeringkiosk.dev/join-discord [https://engineeringkiosk.dev/join-discord]