Vaughn Vernon’s Post

Not all communication is equal. Most software developers and management will argue vigorously the opposite. #DDDesign #ConwaysLaw #TeamTopologies 1. A puzzling take on team communication is that some subset of people on a team of any size must communicate well, while another subset doesn't. 2. Another puzzling idea is that everyone on the team will achieve sense giving and sense reading on the same level. (Although few would actually know what sense giving and sense reading are.) 3. There's also the practice of management forming teams and selecting team members in a vacuum, arbitrarily, with no feedback from technical leaders. 4. There's the extreme opposite of 3, that of full self-selection of teams. The first two of these are not true. Sure, humans and sometimes agree on where to eat lunch or the colors for a team room. Yet, agreeing on the same mental model of a complex software problem and solution just won't easily or even simply happen. Every single person, even identical twins, have different default concepts and heuristics, because they've all learned and experienced things differently and separately. Besides that some blank out on audible or visual, or at least favor one over the other. It takes a lot of careful communication, which is not only audible or written. It requires visualization of concepts, example scenarios written and visual, and patient reputation. The second pair of assumptions are likewise nearsighted. While point 3 is the worst of the two, even team self-selection can lead to deficiencies. One team with a lot of experience and skill could self-select on a clear or complicated problem, while another team could self-select and be ill-equiped to solve a complex problem. Note: Some highly skilled developers work on low-complexity problems so they can introduce complex technical mechanisms, tools, and software development approaches for fun. #TeamTopologies refers to this as cognitive load and focuses on decreasing cognitive load of all teams, with the first priority on stream-aligned teams. The primary problem with all kinds of team compositions is management (a) viewing all developers as equally skilled cogs, (b) not knowing how to determine levels of complexity, and (c) having little idea what's going on within teams. Skill here means mental capacity, clear, concise, complete communication; commitment; technical and software development capabilities; and willingness to challenge everything that they currently assume. This all traces back to Conway’s Law and what I refer to as Conway’s First Axiom: - Communication matters most - First designs are rarely the best - Flexible is required to improve and possibly reform teams based on the need to improve communication and possibly other skills Don't take these for granted. Keep a pulse on all teams involved in a system solution. Adjust as necessary.

Join me for my Fast Track workshops in July. Each half-day is packed with know-how and practice. - #EventStorming 17 July - Tactical #DDDesign 24 July - #DataMesh 30 July *** Info and registration in comment ***

Things software developers need to understand: - The more nodes you add to a cluster, the greater the number of errors (i.e. data loss) will be encountered - If MB will redeliver 1 message per 1 million, you have to treat it as if it's 1:1 - Dig below the brochureware and pre-sales engineering. Those aren't going to pay for your life-critical and/or financial losses once they run the sign-and-date-on-the-line algorithm on you

In messaging, exactly-once delivery is a myth. You've got at-most-once delivery and at-least-once delivery. Don't leave exactly-once delivery *semantics* to your message broker/bus to manage. "The management of uncertainty must be implemented in the business logic" Pat Helland *** Links in comments ***

Well, you don't say. "CISA looked at C/C++ projects and found a lot of C/C++ code." Beyond the obvious, maybe you'll be happy with the pitch for Rust, which is obvious. *** Link in comment ***

Microsoft AI CEO Mustafa Suleyman said that people's work and company IP is "freeware." "Fair use" law has limits. Example: You can quote a relatively brief section of prose with attribution. Consuming the full valuable copyrigted content of websites, books, artwork, etc., and disseminating it is not "fair use." *** Source links in comment ***

I'm certain that I'm not an expert using various LLMs, but I'm sure the LLMs are not expert at interpreting prompts for code generation. It's impressive that certain LLMs that are said to specialize in code generation can roughly understand what I've asked them to do, but the outcomes are nowhere near useful. BTW, it turns out that Dunning-Kruger proved to exhibit what Dunning and Kruger described as the effect. Now what? https://lnkd.in/gj5kYUkH

I've been meaning to ask Nick Tune 🇺🇦 if the Low-Hanging Fruit and Toothpaste are more closely related than the graph indicates. Like, you eat all that fruit, and your s/o used all the toothpaste. The risk to pearily-whites is higher than shown unless you have a vice in your workshop. Maybe I'll get a chance to ask someday, but the queue is long.

If you haven't listened to this Acquired interview with Jensen Huang, you should. There are many things to learn from the dialog and apply to software. *** Link in comment ***

For me, this is the biggest gain in Java increments since lambdas and virtual threads. It's roughly on the level of sliced bread. "Java’s Project Leyden arrives in early-access build" *** Link in comment ***