| Website | https://weave-it.org |
| https://www.linkedin.com/in/kenny-baas/ | |
| BlueSky | https://bsky.app/profile/kenny.weave-it.org |
| Collaborative Software Design | https://collaborative-software-design.com |
In the second episode of this season of Satisfying Software, I talk with @kenny_baas on domains, subdomains, bounded contexts. What are they, what is the difference between them en when do we need which one? (We also talk about naming things)
I had many interesting conversations with Kenny on this topic before, and I am very excited that we recorded parts of it for the podcast! [1/2]
It's hard to resolve major outages when you rely only on centralized command. Distributed debugging and strong psychological safety empower the right person to fix issues, even if they're outside the war room. Liz Fong-Jones shared a Google Cloud outage story where this happened.
Read, watch, or listen: https://virtualddd.com/facilitating-archdes/psychological-safety-incident-response/
#IncidentResponse #PsychologicalSafety #DevOps
One worth trying: before committing to any design decision, ask "What would make this conversation a waste of time?" It forces the group to surface the assumptions underneath the debate before spending forty minutes on the wrong question.
#SoftwareArchitecture #CollaborativeSoftwareDesign #DomainDrivenDesign #DecisionMaking #CognitiveBias
Awareness of this pattern helps, but not enough. Research is direct on this point: it's foolhardy to think we can overcome biases through sheer will. What actually works is nudging yourself in the right direction before the overwhelm kicks in.
Simple rules are that nudge. Not because they make you think less, but because they're the product of having thought carefully in advance.
>>>
Your brain doesn't fail under cognitive overwhelm because it's lazy. It fails because it's doing exactly what it was designed to do: conserving energy by seeking closure as fast as possible.
That's why design sessions get hijacked by naming debates. The room spends forty minutes on what to call a service while the real problem sits untouched underneath. >>>
The bandwagon has a lot of passengers right now, and a lot of talks sound like it. If you are putting together an AI talk for a conference: go beyond the hype. Beyond vibe coding. Ask harder questions. Explore what it means to use AI as part of a disciplined craft, not as a shortcut around it.
That is the talk I want to see more of.
That distinction matters. Because most AI talks I see are about going faster. How to use AI to speed up delivery. How to ship more. How to do more in less time.
Faster to what, exactly? The big ball of mud perhaps?
In my experience, good engineers with AI get faster outcomes. Engineers without discipline get faster output. Those are very different things. And faster output, without the underlying discipline, tends to produce faster rigid architectures too.
>>>
Conference season is here, and AI talks are everywhere. No surprise there.
I use AI tools myself and I see genuine value in them as part of how we work. Not in the "use it or die" sense that the bandwagon market keeps selling. Not as the new shiny object that will solve everything if you just adopt it fast enough. But as a tool that, in the hands of someone with discipline and a clear understanding of the problem, can genuinely help.
>>>
We're quietly curating these connections. Curious to see what patterns emerge across the full collection.
Each story is at https://virtualddd.com/stories-on-facilitating-software-architecture-design and all the heuristics are on https://dddheuristics.com.
#CollaborativeModelling #SoftwareArchitecture #DomainDrivenDesign #Facilitation #VirtualDDD
Gien
Virtual Domain-Driven Design