It will fluctuate with time so it needs to be kept in check. Indeed, some things are commodities so can be decided upfront, but the rest of the functional envelope will change over time. Also make sure you drive the project by risks to have early feedback where it matters most.

This is one of those workshops I like to do with teams from time to time. Didn't do it for a while. I wish this resource was on a safer space than google docs.

Yep, there's no logic engine buried deep in those chatbots. Thinking otherwise is placing faith in some twisted view about emergence...

This kind of articles are always a bit caricatural. Still there is some good advice in there. Keep an eye open for the harmful behaviors.

Of course, don't take everything at face value here. Still this gives good ideas on how to combine some design and architectural ideas together. The whole thing is not really Rust specific.

A long essay but contains a lot of interesting insights. There's definitely more to do design wise to produce software people can really bend to their needs.

Mistakes happen, but shrugging them off with blaming people or pushing them to be more careful is counter-productive. Instead, you want to find the organizational issues which made them possible in the first place.

Nice and short explanation on the design rules Kent Beck had in mind when devising XP. It still generally applies in my opinion.

I'm using the term regularly when dealing with legacy code. Finally remembered when I saw it first.

A good reminder of the reasons why the organization of your tests shouldn't necessarily match the organization of the application code. You don't want fragile tests, do you?