Kenny (Baas) Schwegler

@kenny_baas
661 Followers
178 Following
662 Posts
Co-author Collaborative Software Design: How to facilitate domain modeling decisions. Independent consultant & trainer specialised in technical leadership, software architecture, and #sociotechnical systems design. #DomainDrivenDesign #TeamTopologies #DeepDemocracy
Websitehttps://weave-it.org
LinkedInhttps://www.linkedin.com/in/kenny-baas/
BlueSkyhttps://bsky.app/profile/kenny.weave-it.org
Collaborative Software Designhttps://collaborative-software-design.com
Everyone is trying to figure out how to work with AI, but we also need to understand the risks. The risk isn't that AI produces "bad models", it's that we accept plausible-looking ones without having the correct mental models to validate them.
We can do that by modelling collaboratively. Collaborative modelling is becoming more important as we figure out how to use AI. Join me and @kenny_baas
in our workshop, where we will help you improve the quality of it. https://www.avanscoperta.it/en/training/collaborative-software-design-workshop/
Collaborative Software Design Workshop

Based on the book Collaborative Software Design, we provide you with the facilitation skills needed to guide a group and lead impactful modeling sessions.

Avanscoperta | We are learners!!!

I'm not saying AI tooling can't help. But if we're not measuring actual outcomes, we're just confirming our own bias. Start measuring. Compare cycle times, defect rates, rework. Don't let a feeling of speed substitute for evidence of speed.

And make sure you're not feeding the AI hype industry with false promises.

#SoftwareArchitecture #AI #SoftwareDesign #CognitiveBias

This is a textbook example of what happens when we don't measure. We feel productive, so we assume we are. And that assumption feeds into org-wide decisions about tooling, workflow, and investment.
>>>

If you feel like AI is making you write code faster, how do you know for sure?

METR ran what is probably the most rigorous independent study to date. A proper randomised controlled trial with experienced open-source developers. Developers using AI tools (Cursor Pro with Claude 3.5/3.7) were actually 19% slower. But they believed they were 20% faster. That is a 39-percentage-point gap between perception and reality.
>>>

If you want teams to own architectural decisions responsibly, start by creating coherency around what architecture means in your organisation. Don't copy a definition from a textbook. Work together to define it for your teams, your systems, your context. Make it empirical.

Because you can't take ownership of something nobody can agree on the meaning of.

But we copy-pasted the structure without the part that makes engineering engineering: the empirical rigour. Where's our hypothesis-driven approach? We adopted the frameworks but skipped the scientific thinking underneath them. So it's not that we're doing too much engineering. It's that we're not doing enough of the right kind.
>>>
This connects to something broader. We've borrowed a lot from mechanical engineering as a discipline: the job titles, the frameworks, the processes. And that's fine. Borrowing from established disciplines is normal. Software is relatively new compared to mechanical engineering (the pyramids still stand!).
>>>
Right now, many organisations want teams to take ownership of their own architectural decisions. That's a good ambition. But if we haven't created a shared understanding of what architecture means in our context, we're setting teams up to fail. They might think they're making architectural decisions when they're really just making technology choices without considering the trade-offs that actually make it architecture.
>>>
Architecture is what we call in Dutch a "container word." Everyone fills it with their own meaning. And that's not just a semantic problem. It has real consequences.
>>>

38 answers. Almost all different. "Keep it simple stupid." "The foundation we lay to ensure our building doesn't crumble." "Intelligent design." "A system that works and make things work." "The inside of the black box." "Structure." "Everything in IT that is not hard wired."

That's when it gets interesting. Because if we can't agree on what architecture is, what does it mean when room full of people say they're highly involved in architectural decision making?
>>>