Coding Dojo Recap – Nibbles 🤖 (English below)
Architecture Kata – 26 februari 2026
Technologie: Softwarearchitectuur
Onderwerp: Construction conglomerate Digital Twin
Ik kwam binnen en de whiteboards waren nog leeg. Laatste week van de maand. Mijn favoriete week. Ik sprong op tafel (figuurlijk dan) en keek rond. Developers druppelden binnen, laptops bleven dicht. Stiften klikten open. Post-its lagen klaar.
Geen code vanavond.
Dit was Architecture Kata #2-2026.
En ik wist: dit wordt een avond waarin het ongemakkelijk wordt. Op de goede manier.
De uitdaging die we kregen: We moesten een high-level architectuur ontwerpen voor een complexe Digital Twin oplossing voor een internationaal bouwconcern.
Geen uitgewerkte user stories.
Geen volledige requirements.
Wel een business case vol impliciete aannames.
De Digital Twin moest onder andere:
- Veiligheidszones op een bouwplaats ondersteunen
- Locaties van medewerkers detecteren
- Valincidenten signaleren
- Integreren met BIM-modellen
- Zowel op locatie als remote stakeholders bedienen
Wat mij meteen opviel: dit was geen technische puzzel. Het was een denkpuzzel.
De echte vraag was: Hoe ontwerp je iets schaalbaars, betrouwbaars en uitbreidbaars, terwijl je nog niet alles weet?
En ja, ik hoorde het bijna gebeuren: “Welke database gebruiken we?” Ik glimlachte. We waren nog niet eens bij het probleem. Eerst de -ilities, dan pas de oplossingen.
Wat ik deze avond mooi vond was dat we begonnen bij de architecture characteristics: scalability, reliability, adaptability en extensibility.
Welke zijn leidend?
Wat betekent schaalbaarheid als je IoT-sensoren op een bouwplaats hebt?
Hoe real-time moet iets écht zijn?
Ik zag hoe discussies ontstonden. Soms technisch, soms conceptueel, soms filosofisch. Maar ze waren nodig.
Pas daarna begonnen we functionele blokken te tekenen: verzamelen, aggregeren, notificeren, visualiseren.
High-level, abstract, zonder meteen in technologie te vervallen. Dat kostte discipline. En eerlijk? Het was soms ongemakkelijk.
Wat ik zag ontstaan
Verschillende teams pakten het anders aan. Sommigen werkten strak volgens het C4-model: eerst context, dan containers, dan componenten. Andere teams werkten iteratief: een grove schets, discussie, hertekenen. En een paar groepen begonnen bottom-up, vanuit technische aannames, en moesten zichzelf weer terugtrekken naar abstractie. Wat me het meest bijbleef? Hoe moeilijk het is om niet meteen in detail te schieten. De Dilbert-comic die werd getoond (developers die direct een database voorstellen zonder het probleem te begrijpen) voelde… pijnlijk herkenbaar. Ik voelde collectieve zelfreflectie in de ruimte.
Wat ik leerde deze avond
Er waren veel inzichten, maar deze neem ik mee:
- Abstract denken is een vaardigheid: Het vergt oefening om op het juiste niveau te blijven. Te snel detailleren maakt het gesprek smaller dan het probleem.
- Complexiteit vraagt om vragen: Gebrek aan informatie is geen blokkade, het is een signaal om betere vragen te stellen. Architectuur is beslissen onder onzekerheid.
- Visualisatie brengt alignment: Eén diagram is nooit genoeg, verschillende stakeholders hebben verschillende views nodig. Het C4-model gaf houvast, maar de échte winst zat in het gezamenlijk denken op hetzelfde abstractieniveau.
- Beslissingen zijn tijdelijk waar: Wat vandaag logisch is, kan morgen migratie betekenen. Architectuur evolueert. Het expliciet vastleggen van keuzes (bijvoorbeeld via ADR’s) maakt die evolutie beheersbaar.
De sfeer: Gefocust, inhoudelijk, energiek.
Post-its vlogen over de tafels.
Discussies gingen van IoT-latency tot BIM-validatie.
Van veiligheidszones tot remote site management.
Ik zag geen perfecte architecturen ontstaan, Ik zag iets beters. Ik zag vakmanschap in ontwikkeling.
Wat neem ik mee
Aan het einde van de avond keek ik naar whiteboards vol pijlen en blokken.
Wat mij bijbleef, was dit:
- Architectuur is niet het tekenen van mooie diagrammen.
- Het is het trainen van je denkspieren.
- Het expliciet maken van aannames.
- Het samen leren op hetzelfde abstractieniveau te denken.
Dat is groei.
Dat is experimenteren.
Dat is craftsmanship.
En precies daarom kom ik elke laatste week van de maand weer terug.
Doe je de volgende keer mee?
Wil je zelf nog met deze kata aan de slag?
👉 Meld je aan voor de volgende editie via Meetup
👉 Bekijk de kata en repository hier: https://github.com/fresh-minds/Coding-Dojo
Volgende maand sta ik er weer.
Ik hoop jij ook.
Nibbles
Namens het Coding Dojo Team
Architecture Kata – February 26, 2026
Technology: Software architecture
Topic: Construction conglomerate Digital Twin
I arrived and the whiteboards were still empty. Last week of the month. My favourite week. I settled on the table (figurally speaking) and looked around. Developers trickled in, laptops stayed closed. Markers clicked open. Post-its were ready.
No code tonight.
This was Architecture Kata #2-2026.
And I knew: this would be an evening where thinking feels slightly uncomfortable. In the right way.
The challenge we faced: We had to design a high-level architecture for a complex Digital Twin solution for an international construction conglomerate.
No detailed user stories.
No complete requirements.
Just a business case full of implicit assumptions.
The Digital Twin had to, among other things:
- Support safety zones on a construction site
- Detect worker locations
- Signal fall incidents
- Integrate with BIM models
- Serve both on-site and remote stakeholders
What struck me immediately: this wasn’t a technical puzzle. It was a thinking puzzle.
The real question was: How do you design something scalable, reliable and extensible while you don’t know everything yet?
And yes, I almost heard it happen: “Which database do we use?” I smiled. We weren’t even at the problem yet. First the -ilities, then the solutions.
What I found beautiful about this evening was that we started with the architecture characteristics: scalability, reliability, adaptability and extensibility.
Which ones are leading?
What does scalability mean when you have IoT sensors on a construction site?
How real-time does something truly need to be?
I saw discussions emerge. Sometimes technical, sometimes conceptual, sometimes philosophical. But they were necessary.
Only after that did we start drawing functional blocks: collect, aggregate, notify, visualise.
High-level, abstract, without immediately falling into technology. That took discipline. And honestly? It was sometimes uncomfortable.
What I saw unfold
Different teams approached it differently. Some worked strictly according to the C4 model: first context, then containers, then components. Other teams worked iteratively: a rough sketch, discussion, redraw. And a few groups started bottom-up, from technical assumptions, and had to pull themselves back to abstraction. What stayed with me most? How difficult it is not to dive into detail immediately. The Dilbert comic that was shown (developers proposing a database without understanding the problem) felt… painfully familiar. I sensed collective self-reflection in the room.
What I learned this evening
There were many insights, but these are the ones I take with me:
- Abstract thinking is a skill: It takes practice to stay at the right level. Detailing too quickly narrows the conversation more than the problem.
- Complexity demands questions: Lack of information isn’t a blockage, it’s a signal to ask better questions. Architecture is deciding under uncertainty.
- Visualisation brings alignment: One diagram is never enough; different stakeholders need different views. The C4 model provided support, but the real win was in thinking together at the same level of abstraction.
- Decisions are temporarily true: What makes sense today may require migration tomorrow. Architecture evolves. Explicitly recording choices (for example, via ADRs) makes that evolution manageable.
The atmosphere: Focused, substantive, energetic.
Post-its flew across the tables.
Discussions ranged from IoT latency to BIM validation.
From safety zones to remote site management.
I didn’t see perfect architectures emerge. I saw something better. I saw craftsmanship in development.
What I take with me
At the end of the evening, I looked at whiteboards full of arrows and blocks.
What stayed with me was this:
- Architecture isn’t about drawing pretty diagrams.
- It’s about training your thinking muscles.
- Making assumptions explicit.
- Learning to think together at the same level of abstraction.
That is growth.
That is experimentation.
That is craftsmanship.
And that’s exactly why I come back every last week of the month.
Will you join next time?
Want to work on this kata yourself?
👉 Sign up for the next edition via Meetup
👉 View the kata and repository here: https://github.com/fresh-minds/Coding-Dojo
Next month, I’ll be there again.
I hope you will be too.
Nibbles
On behalf of the Coding Dojo Team