det.social is one of the many independent Mastodon servers you can use to participate in the fediverse.
Mastodon Server des Unterhaltungsfernsehen Ehrenfeld zum dezentralen Diskurs.

Administered by:

Server stats:

1.8K
active users

#softwarearchitecture

10 posts7 participants1 post today

We are thrilled to welcome @VaughnVernon , a thought leader in software architecture, to share his insights on #StochasticArchitecture. 💡

In a world where GenAI is rapidly evolving, Vaughn will explore the fundamental questions: How helpful is #GenAI for software architecture? Can we trust these models, or are they just “stochastic parrots”? 🦜

🔗 Learn more about his keynote 👉 t1p.de/47gca

Watching "The Big OOPs", new 1h50m talk by Casey Muratori about the long and meandering history, mistakes & shortcomings of OOP and looking for better/alternative ways forward...

youtube.com/watch?v=wo84LFzx5n

(Also very interesting for some #PermaComputing & KISS aspects)

www.youtube.com- YouTubeEnjoy the videos and music you love, upload original content, and share it all with friends, family, and the world on YouTube.

If you use a relational model in a service that’s part of an Event-Driven Architecture, you’ve likely run into the transactional outbox pattern.
I’m adding content on it to the Awesome Event-Driven Architecture list soon.

To start: a 5-min video by Wade Waldron explaining how it works.

📺 youtube.com/watch?v=5YLpjPmsPC

I'm positively surprised by the book "Fundamentals of Software Architecture" by
Mark Richards & Neal Ford. I acquired it sometimes ago in a humble bundle and am still in the progress of reading.

To my surprise the last part is focusing on "Technique and Soft Skills", while short they try to strive a lot of areas: risk analyses, presentation, team building, negotiation and leadership.

This is clearly a #book recommendation.

fundamentalsofsoftwarearchitec

fundamentalsofsoftwarearchitecture.comFundamentals of Software ArchitectureCompanion site for the book Fundamentals of Software Architecture by Mark Richards and Neal Ford.
Replied in thread

@RuthMalan It's the "and then" part that's the problem. I write the ADR before making the decision, using it to drive discussion and evaluate options (and record the options, too). That's where most of the value comes from for me.

ADRs are rarely needed afterwards, but when they are (mostly during onboarding of new team members, but maybe also if something doesn't turn out the way we imagined), they are an immensely useful tool for understanding the thinking that went into the decision.

In other words (because I've been thinking about Peter Naur's Theory Building View lately), ADRs can help people (re)build the theory of the system in their minds if necessary, keeping it alive. People who already possess the theory don't need to read them, and this is a good thing.