Engineering Kiosk

Public Money, Public Code: Wenn es sich um öffentliche Gelder handelt, sollte es auch öffentlicher Code sein.Warum zahlen wir eigentlich doppelt? Wir finanzieren Software mit Steuergeld, aber der Code verschwindet hinter verschlossenen Türen. In dieser Episode sprechen wir über Public Money Public Code: Wenn öffentliche Gelder in Software fließen, sollte der Code als Open Source verfügbar sein. Nicht nur fair für die Allgemeinheit, sondern auch strategisch klug für digitale Souveränität und gegen Vendor Lock-in.Gemeinsam mit unserem Gast Johannes Näder, Senior Project Manager Policy bei der Free Software Foundation Europe, tauchen wir in die Praxis ein. Johannes koordiniert die Initiative Public Money Public Code, berät Verwaltung und Politik und hält Vorträge zu nachhaltiger Beschaffung, Openwashing und digitaler Souveränität. Wir klären die Grundlagen freier Software, warum die vier Freiheiten zählen und wieso die Lizenzfrage nicht optional ist. Danach wird es konkret: Wie öffentliche Vergabeverfahren heute funktionieren, was sich mit der EU-Vergabereform ändern könnte, und wie Behörden statt Lizenzpaketen künftig Entwicklung, Maintenance und Support von Open Source einkaufen können.Wir schauen auf Erfolge und Best Practices: Schleswig-Holstein migriert massenhaft auf LibreOffice, das österreichische Bundesheer ist umgestiegen, München investiert wieder in freie Software. Wir sprechen über ZenDiS, den souveränen Arbeitsplatz OpenDesk und die Code-Plattform OpenCode.Bonus: Wer hätte gedacht, dass das österreichische Bundesheer zum (LibreOffice) Vorreiter wird?Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partnersDas schnelle Feedback zur Episode:👍 (top) 👎 (geht so)Anregungen, Gedanken, Themen und WünscheDein Feedback zählt! Erreiche uns über einen der folgenden Kanäle …EngKiosk Community: https://engineeringkiosk.dev/join-discord LinkedIn: https://www.linkedin.com/company/engineering-kiosk/Email: stehtisch@engineeringkiosk.devMastodon: https://podcasts.social/@engkioskBluesky: https://bsky.app/profile/engineeringkiosk.bsky.socialInstagram: https://www.instagram.com/engineeringkiosk/Unterstütze den Engineering KioskWenn du uns etwas Gutes tun möchtest … Kaffee schmeckt uns immer Buy us a coffee: https://engineeringkiosk.dev/kaffeeLinksJohannes Näder auf LinkedIn: https://www.linkedin.com/in/jnaeder/Johannes Näder auf Mastodon: https://mastodon.social/@johasFree Software Foundation Europe: https://fsfe.org/Public Money, Public Code: https://publiccode.eu/de/OSI Approved Licenses: https://opensource.org/licensesFrOSCon - 100 Tage Schwarz-Rot: Ein Aufbruch für Freie Software?: https://media.ccc.de/v/froscon2025-3329-100_tage_schwarz-rot_ein_aufbruch_fur_freie_softwareZentrum für Digitale Souveränität der Öffentlichen Verwaltung: https://www.zendis.de/Deutschland-Stack: https://deutschland-stack.gov.de/OpenDesk: https://www.opendesk.eu/deÖsterreichs Bundesheer stellt auf LibreOffice um: https://www.heise.de/news/Oesterreichs-Bundesheer-stellt-auf-LibreOffice-um-10660756.htmlNach LiMux-Aus: Wie sich München langsam wieder an Open Source annähert: https://www.heise.de/news/Nach-LiMux-Aus-Wie-sich-Muenchen-langsam-wieder-an-Open-Source-annaehert-9980995.htmlNextCloud: https://nextcloud.com/de/FrOSCon 2024 - Geld ist nicht alles! Neue Wege zur nachhaltigen Beschaffung Freier Software: https://media.ccc.de/v/froscon2024-3111-geld_ist_nicht_allesGoogle Cloud und BWI geben Partnerschaft bekannt: https://www.bwi.de/magazin/artikel/google-cloud-und-bwi-geben-partnerschaft-bekanntOpenCode: https://opencode.de/deCorona-Warn-App auf Github: https://github.com/corona-warn-appNext Generation Internet (NGI): https://ngi.eu/Ada & Zangemann - Ein Märchen über Software, Skateboards und Himbeereis: https://fsfe.org/activities/ada-zangemann/index.de.htmlFSFE Contribute: https://fsfe.org/contribute/Software Freedom Podcast: https://fsfe.org/news/podcast.en.htmlSprungmarken(00:00:00) Public Money, Public Code(00:05:02) Worum geht es bei freier Software und "Public Money, Public Code"?(00:06:09) Info/Werbung(00:07:09) Worum geht es bei freier Software und "Public Money, Public Code"?(00:17:04) Wo steht Deutschland bei Public Money, Public Code?(00:23:13) Was ist so schwierig an der Nutzung von Open Source in Behörden?(00:29:13) Vergabeverfahren von Software in der öffentlichen Verwaltung(00:39:57) Positive Beispiele in Behörden(00:48:21) OpenCode und OpenWashing(01:05:29) Was können wir für die Zukunft erwarten?(01:09:44) Was können wir als Bürger tun?HostsWolfgang Gassler (https://gassler.dev) Andy Grunwald (https://andygrunwald.com/)CommunityDiskutiere mit uns und vielen anderen Tech-Spezialist⋅innen in unserer Engineering Kiosk Community unter https://engineeringkiosk.dev/join-discord

Heute geht’s um eine dieser unscheinbaren Technologien, die du wahrscheinlich täglich nutzt: UUIDs! Ob in deiner Datenbank, im Betriebssystem oder in verteilten Systemen. Wie und warum funktionieren UUIDs, welche Versionen gibt es und warum ist nicht jede UUID gleich gut für deine Datenbank.. Außerdem: Alternativen wie Snowflake, ULID oder NanoID..Im Engineering-Kiosk-Adventskalender 2025 sprechen befreundete Podcaster⋅innen und wir selbst, Andy und Wolfi, jeden Tag kurz & knackig innerhalb weniger Minuten über ein interessantes Tech-Thema.Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partnersDas schnelle Feedback zur Episode:👍 (top) 👎 (geht so)Anregungen, Gedanken, Themen und WünscheDein Feedback zählt! Erreiche uns über einen der folgenden Kanäle …EngKiosk Community: https://engineeringkiosk.dev/join-discord LinkedIn: https://www.linkedin.com/company/engineering-kiosk/Email: stehtisch@engineeringkiosk.devMastodon: https://podcasts.social/@engkioskBluesky: https://bsky.app/profile/engineeringkiosk.bsky.socialInstagram: https://www.instagram.com/engineeringkiosk/Unterstütze den Engineering KioskWenn du uns etwas Gutes tun möchtest … Kaffee schmeckt uns immer Buy us a coffee: https://engineeringkiosk.dev/kaffeeLinksThe Problem with Using a UUID Primary Key in MySQL https://planetscale.com/blog/the-problem-with-using-a-uuid-primary-key-in-mysql  Storing UUID Values in MySQL Tables https://dev.mysql.com/blog-archive/storing-uuid-values-in-mysql-tables/ RFC: Universally Unique IDentifiers (UUIDs) https://datatracker.ietf.org/doc/html/rfc9562 Always use the right UUID in MariaDB https://mariadb.org/always-use-the-right-uuid/ UUIDs https://en.wikipedia.org/wiki/Universally_unique_identifier Sprungmarken(00:00:00) UUIDsHostsWolfgang Gassler (https://gassler.dev) Andy Grunwald (https://andygrunwald.com/)CommunityDiskutiere mit uns und vielen anderen Tech-Spezialist⋅innen in unserer Engineering Kiosk Community unter https://engineeringkiosk.dev/join-discord

Warum zum Teufel interessiert man sich für so ein trockenes Thema wie InfoSec? mit Stefan Ebeling und Sven Hauptmann vom Zeroday Podcast.Im Engineering-Kiosk-Adventskalender 2025 sprechen befreundete Podcaster⋅innen und wir selbst, Andy und Wolfi, jeden Tag kurz & knackig innerhalb weniger Minuten über ein interessantes Tech-Thema.Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partnersDas schnelle Feedback zur Episode:👍 (top)  👎 (geht so)Anregungen, Gedanken, Themen und WünscheDein Feedback zählt! Erreiche uns über einen der folgenden Kanäle …EngKiosk Community: https://engineeringkiosk.dev/join-discord LinkedIn: https://www.linkedin.com/company/engineering-kiosk/Email: stehtisch@engineeringkiosk.devMastodon: https://podcasts.social/@engkioskBluesky: https://bsky.app/profile/engineeringkiosk.bsky.socialInstagram: https://www.instagram.com/engineeringkiosk/Unterstütze den Engineering KioskWenn du uns etwas Gutes tun möchtest … Kaffee schmeckt uns immer Buy us a coffee: https://engineeringkiosk.dev/kaffeeLinksZeroday - Der Podcast für Informationssicherheit und Datenschutz: https://0x0d.de/Sprungmarken(00:00:00) Interesse für InfoSecHostsWolfgang Gassler (https://gassler.dev) Andy Grunwald (https://andygrunwald.com/)CommunityDiskutiere mit uns und vielen anderen Tech-Spezialist⋅innen in unserer Engineering Kiosk Community unter https://engineeringkiosk.dev/join-discord

XY-Problem: Frag nicht nach deiner Lösung, sondern erklär das Problem.Im Engineering-Kiosk-Adventskalender 2025 sprechen befreundete Podcaster⋅innen und wir selbst, Andy und Wolfi, jeden Tag kurz & knackig innerhalb weniger Minuten über ein interessantes Tech-Thema.Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partnersDas schnelle Feedback zur Episode:👍 (top) 👎 (geht so)Anregungen, Gedanken, Themen und WünscheDein Feedback zählt! Erreiche uns über einen der folgenden Kanäle …EngKiosk Community: https://engineeringkiosk.dev/join-discord LinkedIn: https://www.linkedin.com/company/engineering-kiosk/Email: stehtisch@engineeringkiosk.devMastodon: https://podcasts.social/@engkioskBluesky: https://bsky.app/profile/engineeringkiosk.bsky.socialInstagram: https://www.instagram.com/engineeringkiosk/Unterstütze den Engineering KioskWenn du uns etwas Gutes tun möchtest … Kaffee schmeckt uns immer Buy us a coffee: https://engineeringkiosk.dev/kaffeeLinksXY-Problem: https://de.wikipedia.org/wiki/XY-ProblemHow To Ask Questions The Smart Way: http://www.catb.org/esr/faqs/smart-questions.htmlThe XY Problem: https://xyproblem.info/Eric S. Raymond: https://de.wikipedia.org/wiki/Eric_S._RaymondSprungmarken(00:00:00) XY-ProblemHostsWolfgang Gassler (https://gassler.dev) Andy Grunwald (https://andygrunwald.com/)CommunityDiskutiere mit uns und vielen anderen Tech-Spezialist⋅innen in unserer Engineering Kiosk Community unter https://engineeringkiosk.dev/join-discord

Wie man mit Smart Home (Home Assistant) anfängt mit Andrej Friesen und Thomas Wiebe von SmartHütte.Im Engineering-Kiosk-Adventskalender 2025 sprechen befreundete Podcaster⋅innen und wir selbst, Andy und Wolfi, jeden Tag kurz & knackig innerhalb weniger Minuten über ein interessantes Tech-Thema.Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partnersDas schnelle Feedback zur Episode:👍 (top) 👎 (geht so)Anregungen, Gedanken, Themen und WünscheDein Feedback zählt! Erreiche uns über einen der folgenden Kanäle …EngKiosk Community: https://engineeringkiosk.dev/join-discord LinkedIn: https://www.linkedin.com/company/engineering-kiosk/Email: stehtisch@engineeringkiosk.devMastodon: https://podcasts.social/@engkioskBluesky: https://bsky.app/profile/engineeringkiosk.bsky.socialInstagram: https://www.instagram.com/engineeringkiosk/Unterstütze den Engineering KioskWenn du uns etwas Gutes tun möchtest … Kaffee schmeckt uns immer Buy us a coffee: https://engineeringkiosk.dev/kaffeeLinksSmartHütte Podcast: https://podcast.smarthuette.de/ Einfach starten  https://smarthuette.de/start-mit-home-assistant/ Home Assistant Green: https://www.home-assistant.io/green/ Home Assistant Yellow: https://www.home-assistant.io/yellow/ Thin Clients und das Projekt TinyMiniMicro: https://www.servethehome.com/introducing-project-tinyminimicro-home-lab-revolution/ Zigbee: https://en.wikipedia.org/wiki/Zigbee Philips Hue: https://www.philips-hue.com/ Ikea Smart Home: https://www.ikea.com/de/de/cat/smart-home-hs001/ SMLIGHT SLZB-06p7 (Zigbee): https://smlight.tech/product/slzb-06p7 SMLIGHT SLZB-MR1 (Zigbee + Thread/Matter): https://smlight.tech/product/slzb-mr1 Zigbee2MQTT: https://www.zigbee2mqtt.io/ ZHA: https://www.home-assistant.io/integrations/zha/ Home Assistant Companion Apps: https://companion.home-assistant.io/ Sprungmarken(00:00:00) Advent, Advent, ein smartes Lichtlein brenntHostsWolfgang Gassler (https://gassler.dev) Andy Grunwald (https://andygrunwald.com/)CommunityDiskutiere mit uns und vielen anderen Tech-Spezialist⋅innen in unserer Engineering Kiosk Community unter https://engineeringkiosk.dev/join-discord

Was macht eine richtig gute Tech-Kultur aus? Ein Tech-Radar hilft zumindest dabei bzw. ist ein guter Indikator dafür. . Du erfährst, wie moderne Tech-Organisationen technologische Entscheidungen strukturieren, dokumentieren und strategisch einsetzen. Warum ein Tech Radar mehr ist als nur ein Katalog, wie du damit Innovation steuerst und was das Ganze mit Autonomie und Standards zu tun hat – genau das erfährst du hier. Schnapp dir einen Kaffee und tauch ein in eine Folge, die technologische Klarheit schafft und Lust auf mehr macht!Im Engineering-Kiosk-Adventskalender 2025 sprechen befreundete Podcaster⋅innen und wir selbst, Andy und Wolfi, jeden Tag kurz & knackig innerhalb weniger Minuten über ein interessantes Tech-Thema.Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partnersDas schnelle Feedback zur Episode:👍 (top)  👎 (geht so)Anregungen, Gedanken, Themen und WünscheDein Feedback zählt! Erreiche uns über einen der folgenden Kanäle …EngKiosk Community: https://engineeringkiosk.dev/join-discord LinkedIn: https://www.linkedin.com/company/engineering-kiosk/Email: stehtisch@engineeringkiosk.devMastodon: https://podcasts.social/@engkioskBluesky: https://bsky.app/profile/engineeringkiosk.bsky.socialInstagram: https://www.instagram.com/engineeringkiosk/Unterstütze den Engineering KioskWenn du uns etwas Gutes tun möchtest … Kaffee schmeckt uns immer Buy us a coffee: https://engineeringkiosk.dev/kaffeeLinksThoughtworks Technology Radar https://www.thoughtworks.com/radar Eigenes Tech Radar bauen https://www.thoughtworks.com/radar/byor Zalando Tech Radar (Open Source tools) https://engineering.zalando.com/posts/2016/05/zalando-tech-radar.html Cloud Native Computing Foundation (CNCF) https://www.cncf.io/reports/cncf-technology-landscape-radar/ Inspirational Technology Radar Examples https://www.workingsoftware.dev/inspirational-technology-radar-examples/ Sprungmarken(00:00:00) Tech RadarHostsWolfgang Gassler (https://gassler.dev) Andy Grunwald (https://andygrunwald.com/)CommunityDiskutiere mit uns und vielen anderen Tech-Spezialist⋅innen in unserer Engineering Kiosk Community unter https://engineeringkiosk.dev/join-discord

Open-Source-Contributions jenseits von Code mit Sujeevan Vijayakumaran und Dirk Deimeke vom TILpod.Im Engineering-Kiosk-Adventskalender 2025 sprechen befreundete Podcaster⋅innen und wir selbst, Andy und Wolfi, jeden Tag kurz & knackig innerhalb weniger Minuten über ein interessantes Tech-Thema.Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partnersDas schnelle Feedback zur Episode:👍 (top) 👎 (geht so)Anregungen, Gedanken, Themen und WünscheDein Feedback zählt! Erreiche uns über einen der folgenden Kanäle …EngKiosk Community: https://engineeringkiosk.dev/join-discord LinkedIn: https://www.linkedin.com/company/engineering-kiosk/Email: stehtisch@engineeringkiosk.devMastodon: https://podcasts.social/@engkioskBluesky: https://bsky.app/profile/engineeringkiosk.bsky.socialInstagram: https://www.instagram.com/engineeringkiosk/Unterstütze den Engineering KioskWenn du uns etwas Gutes tun möchtest … Kaffee schmeckt uns immer Buy us a coffee: https://engineeringkiosk.dev/kaffeeLinksTILpod: https://tilpod.net/Sujeevans Homepage: https://svij.org/Dirks Homepage: https://dirk.deimeke.ruhr/Friday Deployments: https://friday-deployments.com/Sprungmarken(00:00:00) Open-Source-Contributions jenseits von CodeHostsWolfgang Gassler (https://gassler.dev) Andy Grunwald (https://andygrunwald.com/)CommunityDiskutiere mit uns und vielen anderen Tech-Spezialist⋅innen in unserer Engineering Kiosk Community unter https://engineeringkiosk.dev/join-discord

Wenn die Digitalisierung fehlschlägt: The London Ambulance System DisasterWas passiert, wenn Politik alles automatisieren will, ein starres Pflichtenheft ohne Tests verabschiedet und eine kleine Agentur in Rekordzeit ein hochkritisches System auf Visual Basic liefern soll? 1992 ging das Notrufsystem des London Ambulance Service mit einem Big Bang Rollout live. Ohne vollwertige Schulung, ohne belastbare Lasttests und ohne echten Backup-Plan. Das Ergebnis: Fehldispatches, endlose Wartezeiten, Ausnahmezustand in der Leitstelle und ein technischer Kollaps durch ein simples Memory Leak.In dieser Episode sprechen wir über den gesamten Projektverlauf vom London Ambulance System Disaster: Von der Zettelwirtschaft mit Förderband über ein überambitioniertes Automatisierungsvorhaben, NIH-Syndrom in der Ausschreibung, unrealistische Deadlines und Budgets, fehlendes Projektmanagement sowie Quality Assurance. Wir beleuchten die Live-Inbetriebnahme im Oktober 1992, GPS- und Statusprobleme in den Ambulanzen, die Exception-Flut auf den Monitoren, das ungetestete Failover und die Folgen für Personal, Vertrauen und Öffentlichkeit.Wir ordnen das Desaster für die Tech Community ein und ziehen Parallelen zu heute: AI- und Cloud-Rollouts ohne Fallback, Fix-forward statt Rollback, End-to-End- und Lasttests mit realistischen Szenarien, SRE-Praktiken, soziotechnische Systeme, UX in kritischen Workflows und die ethische Verantwortung von Entwicklerinnen. Außerdem: moderne Beispiele wie die Boeing 737 Max und Pandemie-Apps, die zeigen, wie zeitlos diese Learnings sind.Bonus: Das Kernsystem lief auf Visual Basic unter Windows 3. Klingt retro, war aber alles andere als ein Retro-Game.Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partnersDas schnelle Feedback zur Episode:👍 (top) 👎 (geht so)Anregungen, Gedanken, Themen und WünscheDein Feedback zählt! Erreiche uns über einen der folgenden Kanäle …EngKiosk Community: https://engineeringkiosk.dev/join-discord LinkedIn: https://www.linkedin.com/company/engineering-kiosk/Email: stehtisch@engineeringkiosk.devMastodon: https://podcasts.social/@engkioskBluesky: https://bsky.app/profile/engineeringkiosk.bsky.socialInstagram: https://www.instagram.com/engineeringkiosk/Unterstütze den Engineering KioskWenn du uns etwas Gutes tun möchtest … Kaffee schmeckt uns immer Buy us a coffee: https://engineeringkiosk.dev/kaffeeLinksMini Playback Show (Wikipedia): https://de.wikipedia.org/wiki/Mini_Playback_Shown8n: https://n8n.io/London Ambulance Service NHS Trust: https://www.londonambulance.nhs.uk/Podcast “Digitale Anomalie” - #73: Desaster mit Ansage: https://digitaleanomalien.de/73-desaster-mit-ansage/Disaster in London. The LAS case study: https://www.researchgate.net/publication/3792694_Disaster_in_London_The_LAS_case_studyA Comedy of Errors: the London Ambulance Service case study: http://www0.cs.ucl.ac.uk/staff/a.finkelstein/papers/lascase.pdfReport of the Inquiry Into The London Ambulance Service (60 Seiten): http://www0.cs.ucl.ac.uk/staff/A.Finkelstein/las/lascase0.9.pdfWired - Oct. 26, 1992: Software Glitch Cripples Ambulance Service: https://www.wired.com/2009/10/1026london-ambulance-computer-meltdown/The Guardian - London ambulance staff log calls with pen and paper after IT failure: https://www.theguardian.com/society/2017/jan/01/london-ambulance-staff-log-calls-with-pen-and-paper-after-it-failureEngineering Kiosk Episode #96 Selbstgemacht vs. Fertigprodukt: Ein Blick auf das Not-Invented-Here-Phänomen: https://engineeringkiosk.dev/podcast/episode/96-selbstgemacht-vs-fertigprodukt-ein-blick-auf-das-not-invented-here-ph%C3%A4nomen/LASCAD (Wikipedia): https://en.wikipedia.org/wiki/LASCADSprungmarken(00:00:00) 1992 und das London Ambulance System Disaster(00:06:01) Info/Werbung(00:07:01) 1992 und das London Ambulance System Disaster(00:42:37) Aus Fehlern lernen: End-to-End und Lasttests(00:47:38) Aus Fehlern lernen: Die menschliche Seite(00:55:32) Projekte mit anderen Problemen in der heutigen ZeitHostsWolfgang Gassler (https://gassler.dev) Andy Grunwald (https://andygrunwald.com/)CommunityDiskutiere mit uns und vielen anderen Tech-Spezialist⋅innen in unserer Engineering Kiosk Community unter https://engineeringkiosk.dev/join-discord

Yak Shaving: Warum du dich auf das richtige Problem konzentrieren solltest.Im Engineering-Kiosk-Adventskalender 2025 sprechen befreundete Podcaster⋅innen und wir selbst, Andy und Wolfi, jeden Tag kurz & knackig innerhalb weniger Minuten über ein interessantes Tech-Thema.Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partnersDas schnelle Feedback zur Episode:👍 (top) 👎 (geht so)Anregungen, Gedanken, Themen und WünscheDein Feedback zählt! Erreiche uns über einen der folgenden Kanäle …EngKiosk Community: https://engineeringkiosk.dev/join-discord LinkedIn: https://www.linkedin.com/company/engineering-kiosk/Email: stehtisch@engineeringkiosk.devMastodon: https://podcasts.social/@engkioskBluesky: https://bsky.app/profile/engineeringkiosk.bsky.socialInstagram: https://www.instagram.com/engineeringkiosk/Unterstütze den Engineering KioskWenn du uns etwas Gutes tun möchtest … Kaffee schmeckt uns immer Buy us a coffee: https://engineeringkiosk.dev/kaffeeLinksHerkunft von Yak Shaving: https://en.wiktionary.org/wiki/yak_shavingRen & Stimpy, Yak Shaving Day: https://en.wikipedia.org/wiki/The_Boy_Who_Cried_Rat!Am I Yak-Shaving or Bikeshedding?: https://kau.sh/blog/yak-shaving-bike-shedding/Don’t Shave That Yak!: https://seths.blog/2005/03/dont_shave_that/yak shaving: http://www.catb.org/~esr/jargon/html/Y/yak-shaving.htmlParkinsonsche Gesetze: https://de.wikipedia.org/wiki/Parkinsonsche_Gesetze"Jeremy H. Brown" to: all-ai@ai.mit.edu: https://projects.csail.mit.edu/gsb/old-archive/gsb-archive/gsb2000-02-11.htmlStack Exchange “What exactly is Yak Shaving?”: https://softwareengineering.stackexchange.com/questions/388092/what-exactly-is-yak-shavingHistory of Apache Maven: https://maven.apache.org/background/history-of-maven.htmlSlack (software): https://en.wikipedia.org/wiki/Slack_(software)HostsWolfgang Gassler (https://gassler.dev) Andy Grunwald (https://andygrunwald.com/)CommunityDiskutiere mit uns und vielen anderen Tech-Spezialist⋅innen in unserer Engineering Kiosk Community unter https://engineeringkiosk.dev/join-discord

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/partnersDas schnelle Feedback zur Episode:👍 (top) 👎 (geht so)Anregungen, Gedanken, Themen und WünscheDein Feedback zählt! Erreiche uns über einen der folgenden Kanäle …EngKiosk Community: https://engineeringkiosk.dev/join-discord LinkedIn: https://www.linkedin.com/company/engineering-kiosk/Email: stehtisch@engineeringkiosk.devMastodon: https://podcasts.social/@engkioskBluesky: https://bsky.app/profile/engineeringkiosk.bsky.socialInstagram: https://www.instagram.com/engineeringkiosk/Unterstütze den Engineering KioskWenn du uns etwas Gutes tun möchtest … Kaffee schmeckt uns immer Buy us a coffee: https://engineeringkiosk.dev/kaffeeLinksEngineering Kiosk #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/envoy Request Hedging: https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/http/http_routing#request-hedginggRPC Request Hedging: https://grpc.io/docs/guides/request-hedging/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?HostsWolfgang Gassler (https://gassler.dev) Andy Grunwald (https://andygrunwald.com/)CommunityDiskutiere mit uns und vielen anderen Tech-Spezialist⋅innen in unserer Engineering Kiosk Community unter https://engineeringkiosk.dev/join-discord

SOLID: Single-Responsibility, Open-Closed, Liskovsche Substitution, Interface-Segregation und Dependency-InversionSOLID 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/partnersDas schnelle Feedback zur Episode:👍 (top) 👎 (geht so)Anregungen, Gedanken, Themen und WünscheDein Feedback zählt! Erreiche uns über einen der folgenden Kanäle …EngKiosk Community: https://engineeringkiosk.dev/join-discord LinkedIn: https://www.linkedin.com/company/engineering-kiosk/Email: stehtisch@engineeringkiosk.devMastodon: https://podcasts.social/@engkioskBluesky: https://bsky.app/profile/engineeringkiosk.bsky.socialInstagram: https://www.instagram.com/engineeringkiosk/Unterstütze den Engineering KioskWenn du uns etwas Gutes tun möchtest … Kaffee schmeckt uns immer Buy us a coffee: https://engineeringkiosk.dev/kaffeeLinksEngineering 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/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/Engineering Kiosk 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)Urlaub im Userspace: E011 – 30 Jahre MySQL mit Wolfi 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?HostsWolfgang Gassler (https://gassler.dev) Andy Grunwald (https://andygrunwald.com/)CommunityDiskutiere mit uns und vielen anderen Tech-Spezialist⋅innen in unserer Engineering Kiosk Community unter https://engineeringkiosk.dev/join-discord

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/partnersDas schnelle Feedback zur Episode:👍 (top) 👎 (geht so)Anregungen, Gedanken, Themen und WünscheDein Feedback zählt! Erreiche uns über einen der folgenden Kanäle …EngKiosk Community: https://engineeringkiosk.dev/join-discord LinkedIn: https://www.linkedin.com/company/engineering-kiosk/Email: stehtisch@engineeringkiosk.devMastodon: https://podcasts.social/@engkioskBluesky: https://bsky.app/profile/engineeringkiosk.bsky.socialInstagram: https://www.instagram.com/engineeringkiosk/Unterstütze den Engineering KioskWenn du uns etwas Gutes tun möchtest … Kaffee schmeckt uns immer Buy us a coffee: https://engineeringkiosk.dev/kaffeeLinksLotum: https://lotum.com/deFabi Fink auf LinkedIn: https://www.linkedin.com/in/fabian-fink-b1a606132/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/PixiJS - The HTML5 Creation Engine: https://pixijs.com/Vue.js: https://vuejs.org/SpacetimeDB: https://spacetimedb.com/Nakama: https://heroiclabs.com/nakama/Firebase: https://firebase.google.com/Google AdMob: https://admob.google.com/intl/de/home/ROAS (Return on Advertising Spend): https://omr.com/de/daily/glossary/roas-return-on-advertising-spendPick of the DayFabi Fink - AINews Smok: https://news.smol.ai/Andy Grunwald - Spiele für Softwareentwickler:innen - https://engineeringkiosk.dev/spiele-fuer-softwareentwickler/Wolfi Gassler: 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 DayHostsWolfgang Gassler (https://gassler.dev) Andy Grunwald (https://andygrunwald.com/)CommunityDiskutiere mit uns und vielen anderen Tech-Spezialist⋅innen in unserer Engineering Kiosk Community unter https://engineeringkiosk.dev/join-discord

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/partnersDas schnelle Feedback zur Episode:👍 (top) 👎 (geht so)Anregungen, Gedanken, Themen und WünscheDein Feedback zählt! Erreiche uns über einen der folgenden Kanäle …EngKiosk Community: https://engineeringkiosk.dev/join-discord LinkedIn: https://www.linkedin.com/company/engineering-kiosk/Email: stehtisch@engineeringkiosk.devMastodon: https://podcasts.social/@engkioskBluesky: https://bsky.app/profile/engineeringkiosk.bsky.socialInstagram: https://www.instagram.com/engineeringkiosk/Unterstütze den Engineering KioskWenn du uns etwas Gutes tun möchtest … Kaffee schmeckt uns immer Buy us a coffee: https://engineeringkiosk.dev/kaffeeLinksWebsite von Michael Dorner: https://www.michaeldorner.de/Veröffentlichungen von Michael Dorner: https://scholar.google.de/citations?user=pxjtc20AAAAJ&hl=de&oi=aoDr. Arbeit von Michael Dorner “Code Review as a Communication Network”: https://bth.diva-portal.org/smash/get/diva2:1991183/FULLTEXT02.pdfInner Source: https://de.wikipedia.org/wiki/Inner_SourceAI 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/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-ForschungHostsWolfgang Gassler (https://gassler.dev) Andy Grunwald (https://andygrunwald.com/)CommunityDiskutiere mit uns und vielen anderen Tech-Spezialist⋅innen in unserer Engineering Kiosk Community unter https://engineeringkiosk.dev/join-discord

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/partnersDas schnelle Feedback zur Episode:👍 (top) 👎 (geht so)Anregungen, Gedanken, Themen und WünscheDein Feedback zählt! Erreiche uns über einen der folgenden Kanäle …EngKiosk Community: https://engineeringkiosk.dev/join-discord LinkedIn: https://www.linkedin.com/company/engineering-kiosk/Email: stehtisch@engineeringkiosk.devMastodon: https://podcasts.social/@engkioskBluesky: https://bsky.app/profile/engineeringkiosk.bsky.socialInstagram: https://www.instagram.com/engineeringkiosk/Unterstütze den Engineering KioskWenn du uns etwas Gutes tun möchtest … Kaffee schmeckt uns immer Buy us a coffee: https://engineeringkiosk.dev/kaffeeLinksThe Invisible $1.52 Trillion Problem: Clunky Old Software: https://www.wsj.com/tech/personal-tech/the-invisible-1-52-trillion-problem-clunky-old-software-f5cbba27Engineers Spend 33% of Their Time Dealing with Technical Debt: https://hackernoon.com/engineers-spend-33percent-of-their-time-dealing-with-technical-debt-ze1p3wftMeasuring 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.04374Paying down tech debt: https://newsletter.pragmaticengineer.com/p/paying-down-tech-debtThe hidden costs of technical debt: https://divagatio.substack.com/p/the-hidden-costs-of-technical-debtBusiness costs of technical debt: https://codescene.com/hubfs/calculate-business-costs-of-technical-debt.pdfThis Code is CRAP: https://testing.googleblog.com/2011/02/this-code-is-crap.htmlSonos 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/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-25010Sprungmarken(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 verhindernHostsWolfgang Gassler (https://gassler.dev) Andy Grunwald (https://andygrunwald.com/)CommunityDiskutiere mit uns und vielen anderen Tech-Spezialist⋅innen in unserer Engineering Kiosk Community unter https://engineeringkiosk.dev/join-discord

Bug-Management muss man wollen … und können – Teil #2Du kennst das Gefühl: Die Bug-Liste wird immer länger, die Zeit aber immer knapper – und plötzlich stehen Feature-Wünsche und Qualitätsansprüche Kopf an Kopf im Sprint. Willkommen im ganz normalen Entwickler:innen-Wahnsinn!In dieser Episode tauchen wir tief ein in die zweite Runde unseres Bugmanagement-Doppelpacks: Wir klären, wie du mit alternden Bugs umgehst, warum manchmal ein kompletter Bug-Löschantrag oder gar eine „Buginsolvenz“ sinnvoll ist, wie du Frust auf Kundenseite vermeidest und was Priorisierung in der Praxis bedeutet. Wir diskutieren Zero-Bug-Policies, Team-Taktiken fürs gemeinsame Backlog-Aufräumen, Root-Cause-Analysen und Deadlines, die aus harmlosen Fehlerchen plötzlich Release-Blocker machen können. Dabei streifen wir Themen wie Maintenance-Kultur, Feature-vs.-Bugfix-Balance (KTLO vs. Verbesserung), Testing-Strategien von Unit bis Canary Deployment, den Sinn (und Unsinn) von Bugsmash-Days und welche Metriken wirklich zeigen, ob sich der gesamte Aufwand am Ende lohnt.Außerdem nehmen wir die menschliche Seite unter die Lupe: Welche Rollen und Verantwortlichkeiten braucht’s eigentlich für ein wirksames Bugmanagement? Wann wird ein Bug zu einem Incident? Und wie schaffst du es, Bugfixing auf Leadership-Ebene gebührend anzuerkennen, statt nur im Schatten der Feature-Entwicklung zu dümpeln?Fun Fact: Je länger ein Bug lebt, desto schwerer wird’s mit dem Fix – oder er verschwindet ganz von allein (aka Buginsolvenz).Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partnersDas schnelle Feedback zur Episode:👍 (top) 👎 (geht so)Anregungen, Gedanken, Themen und WünscheDein Feedback zählt! Erreiche uns über einen der folgenden Kanäle …EngKiosk Community: https://engineeringkiosk.dev/join-discord LinkedIn: https://www.linkedin.com/company/engineering-kiosk/Email: stehtisch@engineeringkiosk.devMastodon: https://podcasts.social/@engkioskBluesky: https://bsky.app/profile/engineeringkiosk.bsky.socialInstagram: https://www.instagram.com/engineeringkiosk/Unterstütze den Engineering KioskWenn du uns etwas Gutes tun möchtest … Kaffee schmeckt uns immer Buy us a coffee: https://engineeringkiosk.dev/kaffeeLinksKeineSprungmarken(00:00:00) Bug Management, die Zweite(00:00:50) Muss ich die Bugs überhaupt fixen?(00:04:20) Info/Werbung(00:05:20) Muss ich die Bugs überhaupt fixen?(00:18:24) Zeit und Raum fürs Team, Bugs zu fixen(00:29:42) Bug-Sprints und Deadline für Bugs(00:33:29) Wer kümmert sich um Bugs?(00:37:52) Bugs als Incidents(00:46:05) Root-Cause-Analysen für Bugs(00:49:36) Bugs von vornherein verhindern(00:58:44) Wie misst man sein Bug-Management?HostsWolfgang Gassler (https://gassler.dev) Andy Grunwald (https://andygrunwald.com/)CommunityDiskutiere mit uns und vielen anderen Tech-Spezialist⋅innen in unserer Engineering Kiosk Community unter https://engineeringkiosk.dev/join-discord

Bug-Management muss man wollen … und können.Jede:r von uns kennt sie: Bugs in der Software. Sie verstecken sich nicht nur in tiefen Architekturentscheidungen oder Skurrilitäten des Nutzerverhaltens. Sie sind Alltag, egal wie viel Testautomatisierung, KI-Unterstützung oder Code-Reviews wir in unseren Prozessen haben. Doch wie gehst du damit um, wenn die Bugliste immer länger wird, dein Team über Jira-Tickets stöhnt und die Frage im Raum steht: Lohnt es sich überhaupt, Bugs systematisch zu managen?In dieser Episode nehmen wir dich mit durch alle Facetten des modernen Bug-Managements. Wir diskutieren, wie Bugs überhaupt entstehen, warum 'Zero Bug'-Versprechen ein Mythos sind und welche Strategien es gibt, Fehler möglichst früh zu finden. Ob durch Beta-Channels, Dogfooding im eigenen Unternehmen oder kreatives Recruiting. Wir tauchen ein in die Welt der Bug Reports: Wie sieht ein richtig guter aus? Welche Infos braucht das Engineering und wie senkst du die Hürden, damit dein Team (und auch die Community) wirklich meldet? Klartext gibt’s auch zur Priorisierung: Wie klassifizierst du Bugs nach User-Impact, Komplexität und Business-Wert, anstatt an zu vielen bunten Jira-Feldern zu verzweifeln?Neugierig? Dann bleib dran.Bonus: Unerwartete Funfact-Challenge → Ist schlechte UX ein Bug oder ein Feature?Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partnersDas schnelle Feedback zur Episode:👍 (top) 👎 (geht so)Anregungen, Gedanken, Themen und WünscheDein Feedback zählt! Erreiche uns über einen der folgenden Kanäle …EngKiosk Community: https://engineeringkiosk.dev/join-discord LinkedIn: https://www.linkedin.com/company/engineering-kiosk/Email: stehtisch@engineeringkiosk.devMastodon: https://podcasts.social/@engkioskBluesky: https://bsky.app/profile/engineeringkiosk.bsky.socialInstagram: https://www.instagram.com/engineeringkiosk/Unterstütze den Engineering KioskWenn du uns etwas Gutes tun möchtest … Kaffee schmeckt uns immer Buy us a coffee: https://engineeringkiosk.dev/kaffeeLinksKeineSprungmarken(00:00:00) Bug Management: Sollten Bugs überhaupt gemanaged werden?(00:04:55) Info/Werbung(00:05:55) Bug Management: Sollten Bugs überhaupt gemanaged werden?(00:21:36) Was ist eigentlich ein Bug?(00:27:22) Bugs richtig reporten: Metadaten, Barrieren und Ticket-Ping-Pong(00:39:22) Bug-Triage: Kategorisierungen, SLOs und Impact eines Bugs(00:50:47) Episode 2 zum Thema Bug ManagementHostsWolfgang Gassler (https://gassler.dev) Andy Grunwald (https://andygrunwald.com/)CommunityDiskutiere mit uns und vielen anderen Tech-Spezialist⋅innen in unserer Engineering Kiosk Community unter https://engineeringkiosk.dev/join-discord

Datenbanken sind das Rückgrat vieler Anwendungen, aber wie konsistent sind deine Daten eigentlich? Egal ob Banküberweisung, Sneaker-Kauf im Online-Shop oder das neueste Side-Project: Oft verbergen sich hinter der vermeintlich „sicheren“ Datenhaltung komplexe Stolperfallen. Wie funktionieren Transaktionen wirklich? Und warum kann ausgerechnet ein falsch gewähltes Isolationslevel zu Dirty Reads, non-repeatable Reads oder sogar zu Write Skew führen?Wir nehmen dich in dieser Episode mit auf eine Reise in die Tiefen der Konsistenzmodelle. Wolfi ist ehemaliger Forscher für Datenbanksysteme an der Uni Innsbruck. Mit ihm steigen wir ein in die Praxis und Theorie; Von Foreign Keys und Check Constraints bis hin zur Multi-Version Concurrency Control (MVCC). Du erfährst, was sich hinter Serializable, Repeatable Read, Read Committed und Read Uncommitted verbirgt und weshalb Tools wie Jepsen immer neue Fehler in selbst „sicheren“ Systemen aufdecken.Am Ende weißt du, warum dich auch als Entwickler:in das Thema Konsistenz, Isolationslevel und Transaktionsmanagement beschäftigen solltest.Bonus: Dirty Reads sind wie Gerüchte: Man hört sie, bevor sie wahr sind… aber was, wenn sie nie stimmen?Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partnersDas schnelle Feedback zur Episode:👍 (top) 👎 (geht so)Anregungen, Gedanken, Themen und WünscheDein Feedback zählt! Erreiche uns über einen der folgenden Kanäle …EngKiosk Community: https://engineeringkiosk.dev/join-discord LinkedIn: https://www.linkedin.com/company/engineering-kiosk/Email: stehtisch@engineeringkiosk.devMastodon: https://podcasts.social/@engkioskBluesky: https://bsky.app/profile/engineeringkiosk.bsky.socialInstagram: https://www.instagram.com/engineeringkiosk/Unterstütze den Engineering KioskWenn du uns etwas Gutes tun möchtest … Kaffee schmeckt uns immer Buy us a coffee: https://engineeringkiosk.dev/kaffeeLinksMySQL's Terrible ACID https://pigsty.io/blog/db/bad-mysql/Jepsen Consistency Phenomena: https://jepsen.io/consistency/phenomenaJepsen Consistency Models: https://jepsen.io/consistency/modelsAantithesis Reliability Glossar - Consistency Models: https://antithesis.com/resources/reliability_glossary/#consistency-modelsEngineering Kiosk Episode #22 NoSQL: ACID, BASE, Ende einer Ära Teil 2: https://engineeringkiosk.dev/ep22 Engineering Kiosk Episode #91 Konsistent, Verfügbar, Ausfalltolerant oder Performant: Das CAP- und PACELC-Theorem in verteilten Systemen: https://engineeringkiosk.dev/ep91 Engineering Kiosk Episode #19 Datenbank-Deepdive (oder das Ende einer Ära): von Redis bis ClickHouse: https://engineeringkiosk.dev/ep19 Engineering Kiosk Episode #189 Fuzzing: Wenn der Zufall dein bester Tester ist mit Prof. Andreas Zeller: https://engineeringkiosk.dev/ep189 Sprungmarken(00:00:00) Konsistenzmodelle von Datenbanken(00:05:43) Info/Werbung(00:06:43) Konsistenzmodelle von Datenbanken(00:15:15) Crash-Kurs Datenbanken: ACID, BASE und CAP(00:27:52) Warum sollten sich Entwickler*innen mit Konsistenz oder Isolationsmodellen auseinandersetzen?(00:33:57) Isolation: Serializable(00:37:16) Isolation: Read uncommitted, Read Committed und Repeatable Read(00:45:38) Phantom Reads, Dirty Reads und Write Skew(00:50:27) Testing und Debugging(00:56:09) Technische Umsetzung von Konsistenzmodellen in Datenbanken(01:01:53) Wer sollte sich um Konsistenzmodelle und Isolationslevel kümmern?HostsWolfgang Gassler (https://gassler.dev) Andy Grunwald (https://andygrunwald.com/)CommunityDiskutiere mit uns und vielen anderen Tech-Spezialist⋅innen in unserer Engineering Kiosk Community unter https://engineeringkiosk.dev/join-discord

Client SDKs: Die schöneren APIs?APIs sind das Rückgrat moderner Softwareentwicklung, doch wer kennt nicht das Dilemma? Die API ändert sich, Fehlermeldungen stapeln sich im Postfach, und plötzlich hängt dein Workflow am seidenen HTTP-Thread. Genau dort kommen Client SDKs ins Spiel. Sie machen aus kryptischen API-Endpunkten handliche, sprachnahe Werkzeuge, die dir nicht nur Nerven, sondern auch Zeit sparen.In dieser Episode schauen wir hinter die Kulissen der SDK-Entwicklung. Wir sprechen aus Maintainer-Perspektive über Supportdruck, Burnout und die (oft unterschätzte) Verantwortung in Open Source. Gleichzeitig tauchen wir tief in die Praxis ein: Was ist ein Client SDK genau? Wann lohnt sich Handarbeit, wann die Code-Generation? Warum ist idiomatisches SDK-Design mehr als nur Style – und weshalb boosten einige SDKs wie das von Stripe oder AWS sogar den wirtschaftlichen Erfolg ganzer Unternehmen?Gemeinsam werfen wir einen Blick auf Architektur, Best Practices, Edge Cases, Testing, Dokumentation und Wartung. Und natürlich diskutieren wir, wann ein SDK wirklich sinnvoll ist – und in welchen Fällen du lieber einen simplen HTTP-Aufruf selbst schreibst.Bonus: Wieso Atlassian Merch statt Sponsoring schickt.Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partnersDas schnelle Feedback zur Episode:👍 (top) 👎 (geht so)Anregungen, Gedanken, Themen und WünscheDein Feedback zählt! Erreiche uns über einen der folgenden Kanäle …EngKiosk Community: https://engineeringkiosk.dev/join-discord LinkedIn: https://www.linkedin.com/company/engineering-kiosk/Email: stehtisch@engineeringkiosk.devMastodon: https://podcasts.social/@engkioskBluesky: https://bsky.app/profile/engineeringkiosk.bsky.socialInstagram: https://www.instagram.com/engineeringkiosk/Unterstütze den Engineering KioskWenn du uns etwas Gutes tun möchtest … Kaffee schmeckt uns immer Buy us a coffee: https://engineeringkiosk.dev/kaffeeLinksEngineering Kiosk Episode #204 Resilience Engineering: Timeouts, Jitter, Backoff & andere Systemretter: https://engineeringkiosk.dev/podcast/episode/204-resilience-engineering-timeouts-jitter-backoff-andere-systemretter/Go library for accessing the GitHub v3 API: https://github.com/google/go-githubGo client library for Atlassian Jira: https://github.com/andygrunwald/go-jiraSemantic Versioning 2.0.0: https://semver.org/go-github “feat: Allow blocking until primary rate limit is reset #3117”: https://github.com/google/go-github/pull/3117Ollama OpenAI API Kompatibilität: https://ollama.com/blog/openai-compatibilitySmithy: https://smithy.io/Introducing AWS API models and publicly available resources for AWS API definitions: https://aws.amazon.com/de/blogs/aws/introducing-aws-api-models-and-publicly-available-resources-for-aws-api-definitions/TypeSpec: https://typespec.io/Engineering Kiosk Episode #214 Daten aus Spotify & Co: Architektur einer skalierbaren API-Data-Pipeline: https://engineeringkiosk.dev/podcast/episode/214-daten-aus-spotify-co-architektur-einer-skalierbaren-api-data-pipeline/Engineering Kiosk Episode #126 Killing the Mutant: Teststrategien mit Sebastian Bergmann: https://engineeringkiosk.dev/podcast/episode/126-killing-the-mutant-teststrategien-mit-sebastian-bergmann/Engineering Kiosk Episode #175 Von Lustig bis Traurig: Wenn Open Source Geschichten schreibt: https://engineeringkiosk.dev/podcast/episode/175-von-lustig-bis-traurig-wenn-open-source-geschichten-schreibt/Sprungmarken(00:00:00) Eine kleine Geschichte über die Entwicklung von Client SDKs(00:04:26) Info/Werbung(00:05:26) Eine kleine Geschichte über die Entwicklung von Client SDKs(00:21:32) Wer schreibt SDKs? SDKs können die Produkte boosten(00:27:16) Welche Code- und Design-Prinzipien sind für ein SDK entscheidend?(00:39:12) Client SDKs auf Basis von Spezifikationen generieren?(00:54:40) Testing von Client SDKs(00:59:52) Wann macht es keinen Sinn, ein Client SDK zu nutzen?HostsWolfgang Gassler (https://gassler.dev) Andy Grunwald (https://andygrunwald.com/)CommunityDiskutiere mit uns und vielen anderen Tech-Spezialist⋅innen in unserer Engineering Kiosk Community unter https://engineeringkiosk.dev/join-discord

Wie würdest du ... Open Podcasts … bauen? Architektur- und Design-Diskussion, die zweite.Monolith oder Microservices? Python oder Go? Wer träumt nachts eigentlich vom perfekten ETL-Stack? Als Softwareentwickler:in kennst du das: Daten aus zig Quellen, kapriziöse APIs, Security-Bedenken und der Wunsch nach einem skalierbaren, sauberen Architekturkonzept. Fragen über Fragen und etliche mögliche Wege. Welcher ist “der Richtige”?Genau dieses Szenario nehmen wir uns zur Brust: Wolfi hat mit „Open Podcast“ ein reales Projekt gebaut, das Analytics-Daten aus Plattformen wie Spotify, Apple & Co. zusammenführt. Du willst wissen, wie du verteilte APIs knackst, Daten harmonisierst, Backups sicherst und deine Credentials nicht als Excel-Sheet auf den Desktop legst? Komm mit auf unseren Architektur-Deepdive! Andy wird Schritt für Schritt interviewt und challenged, wie er als Engineer, von API-Strategie über Message Queues bis Security und Skalierung, dieses Problem kreativ lösen würde. Nebenbei erfährst du alles Wichtige über Open-Source-Vorteile, Datenbanken (PostgreSQL, Clickhouse), Backups, Monitoring und DevOps. Das Ganze immer garniert mit Learnings aus der echten Praxis.Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partnersDas schnelle Feedback zur Episode:👍 (top) 👎 (geht so)Anregungen, Gedanken, Themen und WünscheDein Feedback zählt! Erreiche uns über einen der folgenden Kanäle …EngKiosk Community: https://engineeringkiosk.dev/join-discord LinkedIn: https://www.linkedin.com/company/engineering-kiosk/Email: stehtisch@engineeringkiosk.devMastodon: https://podcasts.social/@engkioskBluesky: https://bsky.app/profile/engineeringkiosk.bsky.socialInstagram: https://www.instagram.com/engineeringkiosk/Unterstütze den Engineering KioskWenn du uns etwas Gutes tun möchtest … Kaffee schmeckt uns immer Buy us a coffee: https://engineeringkiosk.dev/kaffeeLinksEngineering Kiosk Episode #154 Architektur-Diskussion: Design eines einfachen und robusten Preis-Scrapers: https://engineeringkiosk.dev/podcast/episode/154-architektur-diskussion-design-eines-einfachen-und-robusten-preis-scrapers/Open Podcast: https://openpodcast.dev/Open Podcast auf GitHub: https://github.com/openpodcast/Restic: https://restic.net/Percona XtraBackup: https://www.percona.com/mysql/software/percona-xtrabackupSprungmarken(00:00:00) Wie würdest du ... Open Podcasts bauen?(00:03:35) Info/Werbung(00:04:35) Wie würdest du ... Open Podcasts bauen?(00:14:25) Die Produkt-Fragen: Was muss berücksichtigt werden?(00:25:16) Daten anfragen, vereinheitlichen und die Message Queue(00:41:23) Security: Wie speicherst du Zugangsdaten? Wie machst du Backups?(00:49:08) Monitoring und Continuous Integration (CI)/Continuous Delivery (CD)(00:52:28) Wie wurde das Produkt gebaut?HostsWolfgang Gassler (https://gassler.dev) Andy Grunwald (https://andygrunwald.com/)CommunityDiskutiere mit uns und vielen anderen Tech-Spezialist⋅innen in unserer Engineering Kiosk Community unter https://engineeringkiosk.dev/join-discord

“Die Remote-Arbeitsweise ist die bessere Office-Arbeitsweise”Remote? Homeoffice? Büro? Die Pandemie hat unsere Art zu arbeiten nachhaltig verändert. Doch wie fühlt sich 100% remote heute wirklich an? In dieser Episode tauchen wir tief ein: Was bedeutet es, wenn das Office keinen festen Platz mehr hat und der Arbeitsweg aus wenigen Schritten zwischen Bett und Schreibtisch besteht? Andy teilt seine Erfahrungen aus mehr als drei Jahren im komplett remote geführten Arbeitsumfeld – mit Teams verteilt über Deutschland, Europa und Asien.Wir sprechen offen darüber, worauf es im Remote Setup im Tech-Bereich wirklich ankommt: Wie unterscheiden sich Remote, Homeoffice, Telearbeit und mobiles Arbeiten juristisch und praktisch? Wie wandelst du Isolation in produktive Freiheit um und wo liegen die Stolpersteine bei sozialer Interaktion, Sichtbarkeit, Networking und Karriere? Was tun gegen das berüchtigte "Out of Sight, Out of Mind" und wie helfen Eigeninitiative, asynchrone Kommunikation und eine Portion Mut zu neuen Routinen? Außerdem geht’s um globales Arbeiten über Zeitzonen, Selbstmanagement und die Frage: Ist Remote wirklich für alle die beste Lösung oder doch nur ein spannender Ausflug? Als Bonus gibt es Insights zu Unternehmens-Meetups, virtuelles Teambuilding und Networking-Tricks, die auch introvertierte Entwickler:innen glücklich machen können.Funfact: Wer im Homeoffice keinen Nachbarn zum Quatschen hat, kann auf Meetups setzen – aber Achtung, nach einem Abend Community-Action ist die Batterie schneller leer, als du "Zoom" sagen kannst!Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partnersDas schnelle Feedback zur Episode:👍 (top) 👎 (geht so)Anregungen, Gedanken, Themen und WünscheDein Feedback zählt! Erreiche uns über einen der folgenden Kanäle …EngKiosk Community: https://engineeringkiosk.dev/join-discord LinkedIn: https://www.linkedin.com/company/engineering-kiosk/Email: stehtisch@engineeringkiosk.devMastodon: https://podcasts.social/@engkioskBluesky: https://bsky.app/profile/engineeringkiosk.bsky.socialInstagram: https://www.instagram.com/engineeringkiosk/Unterstütze den Engineering KioskWenn du uns etwas Gutes tun möchtest … Kaffee schmeckt uns immer Buy us a coffee: https://engineeringkiosk.dev/kaffeeLinksTIL057 - Office ist nicht gleich Office: https://tilpod.net/episode/til057-office-ist-nicht-gleich-office3 Years of Extremely Remote Work: https://www.brendangregg.com/blog/2025-05-22/3-years-of-extremely-remote-work.htmlVerordnung über Arbeitsstätten (Arbeitsstättenverordnung - ArbStättV): https://www.gesetze-im-internet.de/arbst_ttv_2004/__2.htmlSprungmarken(00:00:00) Wie ist es eigentlich, 100% remote zu arbeiten?(00:03:43) Wie definierst du Remote-Arbeit, Home-Office oder Telearbeit?(00:03:57) Info/Werbung(00:04:57) Wie definierst du Remote-Arbeit, Home-Office oder Telearbeit?(00:12:54) 100% Remote vs. Hybrid(00:19:13) Wie kompensiert man fehlende Kaffeeküchen-Chats?(00:26:16) Remote Leadership: Rituale, Teamgefühl und hybride Realitäten(00:32:29) Arbeiten über Zeitzonen hinweg(00:41:04) Sichtbarkeit und Karriere im Remote-Modus(00:52:39) Wird es negativ ausgelegt, wenn man keine Remote-Erfahrung hat?(00:58:06) Selbstdisziplin, Proaktivität und IsolationHostsWolfgang Gassler (https://gassler.dev) Andy Grunwald (https://andygrunwald.com/)CommunityDiskutiere mit uns und vielen anderen Tech-Spezialist⋅innen in unserer Engineering Kiosk Community unter https://engineeringkiosk.dev/join-discord