🎙️ Folge 10 - Softwarequalität: Warum „läuft bei mir“ nicht reicht

In dieser Episode sprechen Paul Freund und Daniel Ratke über Softwarequalität - und warum guter Code nicht nur bedeutet, dass etwas kompiliert oder lokal einmal funktioniert.

Es geht um echte Projekt-Erfahrungen: von regulierten Produkten mit Quality Gates und Zertifizierung über „Bananen-Software“, die beim Kunden reift, bis hin zu Features, die ungeprüft weitergegeben werden und dann anderen die Zeit verbrennen.

Wir sprechen darüber, warum Ownership einer der wichtigsten Unterschiede zwischen guten und mittelmäßigen Entwicklern ist, wie sich Testing je nach Kontext verändert und warum AI-generierter Code das Thema Qualität noch wichtiger macht - nicht weniger.

🔥 In dieser Episode:

* Warum Softwarequalität stark vom Kontext abhängt

* Regulierte Produkte, UL-Zertifizierung und echte Verantwortung

* Warum „ich habe es gebaut“ nicht reicht, wenn niemand getestet hat

* Ownership als Qualitätsmerkmal - und warum es Entwickler massiv vom Durchschnitt abhebt

* Warum schneller Output wertlos ist, wenn danach andere alles debuggen müssen

* AI und Codequalität - warum Code schreiben weniger wichtig wird, aber Code prüfen wichtiger

* TDD, Unit Tests, Integration Tests und End-to-End Tests - wann was Sinn macht

* Warum die goldene Mitte oft besser ist als Test-Dogmatismus

* „Bananen-Software“ - wenn Produkte erst beim Kunden reifen

* Microsoft, Windows, Backwards Compatibility und warum große Software nie einfach ist

* Legacy, technische Schulden und warum Testabdeckung langfristig entscheidend wird

* UI Testing, Playwright und warum jeder Button einmal benutzt werden sollte

* Tester vs. Entwickler - warum gute QA kein „zweiter Rang“ ist

* Warum kreative Tester extrem wertvoll sind

* Testautomatisierung als Mindestskill für moderne QA

* Security, DevSecOps, CVE-Scans und automatisierte Checks

* AI Security und warum Open Source durch AI langfristig sicherer werden könnte

* Architektur als Grundlage für gute Testbarkeit

* Event Driven Architecture, Datenorientierung und warum gute Schnitte Tests massiv vereinfachen

* „Works on my machine“ als absolute Untergrenze - nicht als Qualitätsziel

⏱️ Kapitel / Timecodes:

00:00 Intro - heute wird scharf geschossen

00:38 Storytelling: Qualität in regulierten Produkten

02:04 Wenn Entwickler ungeprüften Code weitergeben

03:06 Ownership und Arbeitsweise

05:17 AI macht Qualitätssicherung wichtiger

07:10 TDD, Unit Tests und die goldene Mitte

09:16 Vertrauen, Reviews und gute Übergaben

11:53 Bananen-Software und Testing beim Kunden

12:09 Microsoft, Bugs und globale Auswirkungen

16:14 Wie groß Testing bei Microsoft wirklich sein muss

18:04 Legacy, C++, Python 2/3 und technische Schulden

20:50 Warum Testabdeckung bei Legacy entscheidend ist

22:39 UI Testing, Playwright und Smoke Tests

23:15 Desktop Testing und AutoIt Flashbacks

34:51 Quality Prozesse und Cloud DevOps

36:37 Warum man fremde Features oft besser kaputt testet als eigene

38:09 Kreative Tester und echtes Break-Testing

41:24 QA Engineering, FMEA und sicherheitskritische Systeme

43:03 SaaS, Kundendaten und finanzielle Risiken

47:35 DevSecOps und CVE-Scanning in der Praxis

48:46 AI Security und Open Source

51:28 Best Practices: Pipelines, UI Tests, Testautomatisierung

53:03 Architektur als Teil der Testpyramide

55:51 Event Driven Architecture und testbare Systeme

58:29 Integration Tests und „works on my machine“

1:00:30 Wrap-up - Sharing is caring

📌 Links:

Mehr vom Podcast - https://committomarket.de

Du bist oder suchst Entwickler? - https://auralis.group

Coaching und Beratung! - https://frnd.dev

#tech #engineering #business #podcast #softwareentwicklung #softwarequalität #testing #qa

🎙️ Folge 9 - Agile: Warum fast alle es machen, aber kaum jemand das Gleiche meint

In dieser Episode sprechen Paul Freund und Daniel Ratke über ein Thema, bei dem man sich schnell unbeliebt macht: Agile. Scrum, Kanban, Retros, Story Points, Velocity, Forecasts, Agile Coaches - theoretisch kennt es jeder, praktisch lebt es jede Firma anders.

Es geht um die Frage, was Agile eigentlich lösen soll - und warum es in der Realität oft zwischen zwei Extremen pendelt: auf der einen Seite maximaler Prozess, PI-Planning und Bürokratie, auf der anderen Seite Chaos mit halbfertigen Boards, Tickets ohne Inhalt und Meetings, die nur Verwaltung simulieren.

Dazu sprechen wir darüber, warum Story Points oft nur Stunden mit Extra-Schritten sind, weshalb Velocity-Dashboards schnell in die Irre führen, was gute Retros von kompletter Zeitverschwendung unterscheidet - und warum externe Senior-Leute oder Agile Coaches auf der Metaebene oft mehr Impact haben, als man denkt.

🔥 In dieser Episode:

* Warum „Agile“ heute ein extrem schwammiger Begriff ist

* Wasserfall ist tot - aber ist Agile automatisch besser?

* Wie „maximal gelebtes“ Agile in großen Organisationen aussieht

* Warum zu viel Prozess Teams auch brutal ausbremsen kann

* Wieso pseudo-agile Projekte mit leeren Tickets und schlechten Boards oft noch schlimmer sind

* Retros zwischen echtem Mehrwert, Fremdscham und Eskalation

* Story Points vs. Stunden - und warum dieses Missverständnis fast überall auftaucht

* Warum Velocity und Forecast in vielen Teams überschätzt oder falsch gelesen werden

* Weshalb Dashboards Teams dazu bringen können, das System auszudribbeln

* Warum der Warnruf aus dem Team oft wertvoller ist als jede Kennzahl

* Scrum vs. Kanban - und wann welches Modell besser passt

* Wieso große Teams in Refinements oft dysfunktional werden

* Warum interne Plattform- und Support-Teams ein Sonderfall sind

* Weshalb externe Senior-Leute oft den Vergleichsmaßstab mitbringen, der intern fehlt

* Agile Coaches - teuer, aber manchmal extrem wertvoll

* Warum Prozesse nicht dogmatisch sein dürfen, sondern zum Team und Produkt passen müssen

* Startup-Mode vs. Agile-Prozess - und was in kleinen Teams wirklich praktikabel ist

⏱️ Kapitel / Timecodes:

00:00 Intro - heute wird’s meinungsstark

00:30 Wasserfall vs. Agile

01:55 Best-of/Worst-of Agile-Erfahrungen

02:35 Das „maximal agile“ Großprojekt

04:52 Wenn Boards nur Verwaltung simulieren

08:35 Redmine-Horror und Tooling-Frust

11:35 Wenn Agile gut funktioniert

15:48 Warum große Teams in Refinements schwierig werden

24:53 Retros zwischen Hilfe und Eskalation

30:29 Agile Coaches und ihr echter Mehrwert

35:07 Story Points und die große Verwirrung

38:04 Velocity, Forecasts und Dashboard-Probleme

48:51 Scrum vs. Kanban

58:24 Startup-Mode, Live-Fixes und Geschwindigkeit

1:02:04 Wrap-up

📌 Links:

Mehr vom Podcast - https://committomarket.de

Du bist oder suchst Entwickler? - https://auralis.group

Coaching und Beratung! - https://frnd.dev

#tech #engineering #business #podcast #softwareentwicklung #agile #scrum #kanban

🎙️ Folge 8 - Side Projects: Was sie wirklich beeindruckend macht

In dieser Episode sprechen Paul Freund und Daniel Ratke darüber, warum Side Projects für Entwickler so wertvoll sein können - und was davon in der Praxis wirklich Eindruck macht. Denn ein Side Project ist nicht automatisch stark, nur weil es auf GitHub liegt. Und umgekehrt muss es nicht immer ein riesiges eigenes Produkt sein.

Es geht darum, was gute Side Projects auszeichnet: klare Idee, saubere Struktur, gutes Readme, Screenshots, Demo, Website, CI/CD, gepflegte Issues - und vor allem: Ownership. Also der Unterschied zwischen „ich habe mal ein Tutorial nachgebaut“ und „ich habe etwas gebaut, verstanden, gepflegt und weiterentwickelt“.

Außerdem sprechen wir darüber, warum Open-Source-Contributions oft genauso stark oder sogar stärker sein können als ein eigenes Repo, weshalb Engineering-Blogs unterschätzt werden und warum ein Side Project, das sogar echten Umsatz macht, noch mal ein ganz anderes Signal sendet.

🔥 In dieser Episode:

* Warum Side Projects in Bewerbungen und Interviews so stark wirken können

* Was wirklich beeindruckt

* Warum ein Side Project nicht immer ein eigenes Full Product sein muss

* Open-Source-Contributions als starkes Signal - wenn klar erkennbar ist, was genau dein Beitrag war

* Warum bekannte Open-Source-Repos oder Commits in große Projekte sofort Aufmerksamkeit erzeugen

* GitHub als Aushängeschild - und warum halbfertige Tutorial-Repos eher schaden können

* Private Repos statt alles öffentlich „hinrotzen“

* Engineering Blogs als unterschätztes Karriere-Asset

* Warum Screenshots, visuelle Demos und gute Präsentation oft mehr ausmachen als noch mehr Text

* GitHub Stars - nettes Signal, aber kein echter Qualitätsbeweis

* Side Projects mit Umsatz oder echten Nutzern - warum das ein massiver Ownership- und Business-Indikator ist

* Das Spannungsfeld zwischen Side Projects und Festanstellung

* warum andere sich davon bedroht fühlen

* Side Projects sind kein Muss - und fehlende Zeit ist ein legitimer Kontext

* Warum Marke, Vertrauen und Präsentation oft wertvoller sind als „nur der Code“

* MIT, GPL und Open-Source-Lizenzen - und warum sich der Wert von Code durch AI verändert

⏱️ Kapitel / Timecodes:

00:01 Intro - Sonne, Natur und Side Projects

00:49 Was macht ein Side Project überhaupt beeindruckend?

01:11 Letzte Projekte, die Eindruck gemacht haben

02:17 Side Projects im Interview - Diagrammtool als Showcase

04:15 Open-Source-Contributions statt eigenes Full Project

06:16 Linux Kernel, bekannte Repos und starke Contributions

09:14 Was ein gutes Repo ausmacht

11:01 Readme, Website, Dokumentation und Pipeline

13:45 Was auf GitHub eher schadet als hilft

16:05 Side Projects sind kein Pflichtprogramm

21:57 Screenshots, Videos und visuelle Demos

23:40 Side Projects mit Umsatz - besonders starkes Signal

26:17 Side Projects vs. Freelancing

32:01 Engineering Blogs als unterschätztes Asset

36:16 GitHub Stars - was sie aussagen und was nicht

44:24 Gute Präsentation schlägt reinen Text-Blob

46:43 MIT, GPL und der Wert von Code im AI-Zeitalter

51:21 Wrap-up - Sharing is caring

📌 Links:

Mehr vom Podcast - https://committomarket.de

Du bist oder suchst Entwickler? - https://auralis.group

Coaching und Beratung! - https://frnd.dev

#tech #engineering #business #podcast #softwareentwicklung #sideprojects #opensource #github