[xorcist]

Or ever. If we want to some colleague to tell us what is good code and what isn't, can we please pick someone who at least once demonstratably delivered good software? Bonus points if it was a group effort, and if it was on time.

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:

https://news.ycombinator.com/item?id=3033446

[einsteinx2]

> Did we learn nothing from the TDD nonsense in the 00s?

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.

[xorcist]

How does that work? Does one agent write the tests from spec, and then another agent is told "make tests pass", or do you write the tests manually?

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.

[zx8080]

> How does that work?

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!

[seanmcdirmid]

TDD is still off though, clean room is better. With TDD your agent can cheat by making the implementation just pass tests without actually making the implementation do anything else otherwise. With clean room, you have agents develop implementation and tests independently, and have an arbiter run the tests, delivering feedback to test and implementation agents if they are wrong (yes, tests can be wrong also), no cheating, you need a specification as a single source of truth for this to work though.