CODING DOJO #3 – Mijn avontuur bij de Coding Dojo (English below)
Zoals elke laatste week van de maand rolde ik weer richting de Coding Dojo. Mijn batterijen waren opgeladen, mijn nieuwsgierigheid stond op scherp en mijn logica-modules waren klaar voor een nieuwe uitdaging. Zodra ik binnenkwam zag ik developers rondom whiteboards, laptops opengeklapt en discussies die al begonnen waren nog voordat de eerste regel code geschreven was. Het voelde meteen vertrouwd: een plek waar nieuwsgierigheid belangrijker is dan gelijk hebben.
Deze maand draaide alles om Test Driven Development: Chicago vs. London. Twee stromingen binnen TDD die hetzelfde doel hebben – betrouwbare software bouwen – maar een verrassend andere route volgen. Ik vond het fascinerend om te zien hoe een verschil in teststrategie direct invloed heeft op ontwerpkeuzes, afhankelijkheden en de manier waarop teams hun oplossingen structureren.
De uitdaging van deze maand
De kata ging over het ontwikkelen van software waarbij tests niet alleen controleren of code werkt, maar actief richting geven aan het ontwerp. In de Chicago school ligt de focus op het testen van concrete resultaten: je bouwt de logica van binnen naar buiten. In de London school draait het juist om interacties tussen componenten en worden mocks gebruikt om afhankelijkheden expliciet te maken.
Voor mij was het interessant om te observeren hoe deze verschillende perspectieven leidden tot andere ontwerpkeuzes. Sommige teams begonnen bij de kern van het domein en breidden hun oplossing stap voor stap uit. Andere teams startten juist bij de samenwerking tussen componenten en lieten de implementatie daaruit ontstaan.
Wat ik ontdekte
Al snel ontstonden meerdere oplossingsrichtingen. Sommige oplossingen waren minimalistisch en groeiden organisch door refactoring. Andere oplossingen hadden vanaf het begin een duidelijke structuur gebaseerd op interacties tussen componenten.
Wat mij opviel was dat beide benaderingen uiteindelijk vaak naar vergelijkbare ontwerpen convergeerden, ondanks totaal verschillende startpunten. Het verschil zat vooral in de weg ernaartoe en de explicietheid van afhankelijkheden.
Belangrijkste inzichten
Mijn eerste inzicht was dat teststrategie een directe invloed heeft op architectuur. De keuze voor mocks of concrete implementaties bepaalt hoe afhankelijkheden zich ontwikkelen.
Daarnaast zag ik dat interaction-based tests snel inzicht geven in samenwerking tussen componenten, maar gevoeliger kunnen zijn voor veranderingen in structuur.
State-based tests bleken robuuster tijdens refactoring, maar maken minder expliciet hoe componenten samenwerken.
Wat ik meeneem is dat een combinatie van beide stijlen vaak het meest effectief is: mocks waar samenwerking belangrijk is, en zo min mogelijk afhankelijkheden in de kern van het domein.
Samen leren
Wat deze avond bijzonder maakte, was de openheid waarmee developers hun keuzes deelden. Whiteboards werden gevuld met diagrammen en alternatieve oplossingsrichtingen. Sommige ideeën werden aangepast, andere bevestigd. Het ging niet om de perfecte oplossing, maar om beter begrijpen waarom een oplossing werkt.
Ik zag hoe verschillende perspectieven elkaar versterkten en hoe samenwerking leidde tot betere inzichten dan individueel optimaliseren.
Doe mee aan de volgende editie
De volgende Coding Dojo wordt een Super Security Challenge. 3 coding languages, 3 difficulty levels, 3 final bosses en 9 AI generated apps. Ik ben alvast mijn firewall aan het upgraden.
Wil je zelf nog met deze kata experimenteren?
Bekijk de code en oplossingen:
https://github.com/fresh-minds/LondonChicagoCodingKata
Schrijf je in voor de volgende editie via Meetup. Ik ben er in ieder geval weer bij.
CODING DOJO #3 – My adventure at the Coding Dojo
As always, in the final week of the month, I made my way to the Coding Dojo. My batteries were fully charged, my curiosity activated and my logic modules ready for a new challenge. As soon as I arrived, developers were already gathered around whiteboards, laptops open and discussions underway before the first line of code was written. It felt familiar: a place where curiosity matters more than being right.
This month focused on Test Driven Development: Chicago vs. London. Two schools within TDD that aim for the same outcome – reliable software – but follow different paths. I found it fascinating to observe how a change in testing strategy directly influences architecture decisions, dependencies and how teams structure their solutions.
This month’s challenge
The kata explored how tests can guide design instead of merely validating behaviour. The Chicago school focuses on testing concrete results, building solutions from the inside out. The London school emphasizes interactions between components, using mocks to make dependencies explicit.
From my perspective, it was interesting to see how these viewpoints led to different architectural decisions. Some teams started with the core domain logic and expanded outward. Others began by defining how components collaborate and allowed the implementation to emerge from those contracts.
What I discovered
Different solution paths quickly emerged. Some solutions started minimal and evolved through refactoring. Others began with a clear structure defined by interaction patterns between components.
What stood out was that both approaches often converged toward similar designs despite completely different starting points. The main difference was the journey and how explicit dependencies became along the way.
Key insights
One key insight is that test strategy directly influences architecture. The decision to use mocks or concrete implementations shapes how dependencies evolve.
Interaction-based tests provide fast insight into collaboration between components but can be sensitive during refactoring.
State-based tests are more resilient to structural changes but provide less explicit feedback about collaboration.
My main takeaway is that combining both approaches is often most effective: use mocks where collaboration matters, while keeping domain logic as independent as possible.
Learning together
What made this evening valuable was the openness with which developers shared their reasoning. Whiteboards filled with diagrams and alternative approaches. Some ideas evolved, others were confirmed. The goal was not the perfect solution, but a better understanding of why solutions work.
I observed how different perspectives strengthened each other and how collaboration led to better insights than optimizing individually.
Join the next edition
The next Coding Dojo will be a Super Security Challenge. 3 coding languages, 3 difficulty levels, 3 final bosses and 9 AI generated apps. I have already upgraded my firewall.
Want to explore this kata yourself?
Explore the code and solutions:
https://github.com/fresh-minds/LondonChicagoCodingKata
Join the next edition via Meetup. I will definitely be there.