Uncle Bob has fully embraced AI and is risking becoming part of the problem these days.
Common for all these "industry leaders" is that they all write books and give speeches. I'd rather listen to someone who designed successful software such as git or OpenSSH than someone who designed a salary system in the 90s which, it turns out, was scrapped two years later for being a mess. Giving yourself a stage name is not a merit in itself.
There is something to be said for actually understanding the problem first. Did we learn nothing from the TDD nonsense in the 00s?
The famous InfoQ sudoku software design example was chronicled on HN here and should be required reading for anyone who cares about clean code in practice:
I was never a fan of TDD, but ironically I think it may finally be a good development strategy now with agentic/LLM coding since LLMs do so much better they they have a verifiable goal like passing tests.
It does sound like a possible way to parallelize agentic work, but I'd be surprised if the results are better than a non-TDD approach where the agent would write both tests and code from spec.
I would expect the agent to suffer the same problems humans do with TDD, namely that it is hard or impossible to properly model data ("understand the problem") from tests alone. And if we are to believe Frederick Brooks, as I think we should, a good data model is imperative to good code. That is why TDD failed in the real world, and that problem is excarbated with agentic coding.
It is time we as an engineering discipline sober up about which methodologies work in the real world after decades of empirical data. Name the ten most successful software projects right in front of you now, and I bet that exactly none of them were designed from tests. One would expect at least one, from decades of best selling books on the subject.
In fact, it is high time to put the OOP paradigm under scrutiny and see which promises were delivered on and which weren't. Apart from a few functional languages, mainstream language design got stale for a long time until we finally got Rust and Go which broke with the strict paradigm.
It works well. For those who sell tokens.
As much as the (agentic) processes are more and more complex it guarantees that more tokens will be sold tomorrow. Sell tokens FTW!
It's not that I disagree without you about mutable fields vs params, but the industry so disproportionately on the other side of that issue that I'm surprised this objection is raised as often as it is.
Bring it on! Let's have more persistent data structures in standard libraries. Construct a Map by folding new key-vals onto another (possibly) empty Map.
(Rather than creating an empty map and then mutating its instance fields until it's full)