Join us for a stimulating conversation with Kenny (Baas) Schwegler, co-author of Collaborative Software Design, as we explore the intersection of software architecture, team collaboration, & org culture: youtu.be/Mqbm2kwpsHo podcasts.apple.com/us/podcas… @ChristophLucian

Public education has not produced an educated public.

Every time I talk about the issues and problems surrounding LLM (or Vibe-coded) ***product*** development, I get a bunch of off-topic comments (which the writers seem to think are refutations) along the lines of "but I built this useful small thing for myself." What those people are usually describing is essentially scripting using an LLM. I'm a big fan of scripting. It's risky (I've had scripts delete files they shouldn't have, and connecting them to a database is always problematic), but there's nothing wrong with writing a little script for personal use. Using an LLM for that is just fine—I do it myself—and it's faster than doing it by hand. These scripts are NOT products, however. Product concerns like UX, fault tolerance, speed, security, reliability, deployment pipelines, extensive automated testing, hot updates, incremental scaling, accommodating changing requirements, maintainability, etc., etc., etc., don't apply to a small personal script. Confusing scripts with products is not helpful to anybody, and more to the point, the fact that you can use an LLM to write a script is an utter irrelevance when the topic is product development. All applications of an LLM are not the same, and pretending otherwise leads nowhere useful.

Thanks for having Kenny on! Maybe more authors can make an appearance? 👀

I know people claim they're completely nontechnical and have vibe-coded entire products without any human ever looking at any of the code. Thousands of lines a day or more! they say. Insanely productive! Programming is dead! 🙄 If anybody's actually released a known-bug-free 100% machine-generated product created by a nontechnical person that's good enough that people are actually buying it, please send me a link. … I'm waiting.) I also wonder how many of those nontechnical people understand UX and the like, or does their much-vaunted program work like it was thrown together by somebody's kid cousin in VB? I also wonder if they've ever needed to add or modify a feature and what the token cost of that change was.

Every agile method has retrospectives. The point of them is to find better ways of working. The point is not “talk about our feelings instead of working.” If you aren’t serious about the earnest work of improvement there is little point in any of this.

My experience with LLM-generated code is that it's always wrong somewhere. When I say that, people tell me that we should have the LLM write tests, but those tests will be wrong here and there as well. I guess we could ask the LLM to write tests for the tests, but how does that recursion stop? Humans have to get involved in this process, I think. Sure, one person will be wrong at times, too, but that's what ensemble/mob programming is for.

Working solo can feel faster. Until the fixes come back around. On @mob__mentality, Kenny Baas-Schwegler talks collaboration, DDD, and why shared problem-solving leads to better software in the long run. Watch here: hubs.la/Q041GFGV0 (Book links in the thread.)

To find what is right we must be rid of the accumulation of things we now know to be wrong.

A user story is not a code word for specification or a requirement or any description of work. It is not a ticket. It is not a to-do item. It is not something you can build. The fact that the term has been corrupted by the Jira-slinging ticket-money pseudo-Agile Scrummy culture is a real shame, because it's a valuable concept: A "user story" is literally the user's story. It is a description of a problem, not a solution. It is not a specification. It cannot be estimated. It's the topic of conversation that we have with our users/customers to understand their problems and collaboratively develop the smallest, best solution. The story is not the solution—it's the beginning of the conversation you have to arrive at the solution. A story describes our users' work, not ours. The idea is that the best software solves real problems that real people have, and that, by identifying those problems, we can build something that's actually useful. By working on the software one small problem at a time, we guarantee that every release does something useful. People who talk about user stories being dead never understood what they were to begin with. You cannot build software without them.

From Domain-Driven Design to Collaborative Modeling: How Teams Build Better Software Together youtu.be/Mqbm2kwpsHo podcasts.apple.com/us/podcas… @ChristophLucian

‘Mob programming turns up the dial on collaboration even further, by having everybody on the team work together at a single computer. It may sound ridiculous, but, in a way, it’s “easy mode” for collaboration.’ ― @jamesshore, The Art of Agile Development trello.com/c/Dm2xZSBQ/452-th…

When Architecture Meets Culture: Collaborative Software Design and the Systems That Shape Teams youtu.be/Mqbm2kwpsHo podcasts.apple.com/us/podcas… @ChristophLucian

‘Introverts have been known to pick out seats close to the exit, so they can bail out when they’ve had too much or need a reprieve...This isn’t too much of an issue in our Mob ...you can pick where you want to sit or stand.’ ― Aaron Griffith trello.com/c/RCmW40X7/136-mo… @WoodyZuill

#ThrowbackThursdays In this episode of the Mob Mentality Show, we dive into software development and team dynamics with Mark Shead. Discover how to revolutionize your team's productivity and create a more enjoyable work environment: youtu.be/8yJmuXWgVbU?si=AZOp… @ChristophLucian

‘Jez Humble & @davefarley77 get asked whether they would make any changes to their award-winning software engineering book Continuous Delivery.’ youtu.be/0TIOMG6NEH4?si=8IoO… @CdContent @ModernSoftwareX #ModernSoftwareEngineering