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.

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.

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.

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

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.

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?

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.

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

An excellent piece which explains well why the current "debate" is rotten to the core. There's no good way to engage with those tools without reinforcing some biases. Once the hype cycle is over we have a chance at proper research on the impacts... unfortunately it's not happening now when it's badly needed.

Or how the workflows are badly designed and we're forcing ourselves to adapt to them.

More signs of students being harmed in their learning... they get better grades when using gen AI but their skills drop.

Or why this kind of question never have an absolute answer.

Definitely this, too often I see projects treating the technical debt as one-off large tasks. Really it's something you should deal with bite sized and over time.

Looks like a good approach to integrate LLMs in your development workflow. In case that would become something trustable.

OK, this is definitely concerning for the use of tools with so called coding agents. The trust model is really not appropriate at this stage and that opens the door to a wide range of attacks.

Need to play with file descriptors on Unix systems? This is a fun and gentle introduction.

This is one way to frame it I guess. Code is indeed an investment, tests are here to protect it.

Not fond of the metaphor used here which leads to quite some noise. Still, this article contains interesting ideas to try to push R&D initiatives forward. Definitely needed to improve any kind of organisation.

Interesting paper about metastable failures and novel approaches to try to analyse them. It's early days but we would need to get toward better prevention.