> Well he makes software and writes about software development doesn’t he? Hardware has some hard limitations.

Right.

> The reason software was even invented at all was precisely to escape those limitations.

But the methods which are useful for hardware are also often useful for software. Most of the useful parts of agile were already practiced well before that was a name for anything. And the demonization of the straw-man version of waterfall in order to sell more agile consulting has led to some serious misconceptions of what waterfall really is and what it is really capable of and useful for.

The initial impetus for what became known as TDD was software maintenance, and it makes sense there.

But most TDD practitioners are nowhere near as good at real testing as the waterfall test practitioners who understand that a single missed testcase could delay a $10 million project by six months.

And this is why, even in the realm of software you still see serious efforts for aviation and nuclear power plants, and other things with real-world consequences, using more traditional methods.

I have not seen Kent Beck argue for eXtreme Programming or other Agile methods in nuclear power plant software or aviation. These are niche industries and constitute a vanishingly tiny part of all the lines of code out there I presume.

The fact that short iterations adding features incrementally leads to better outcomes for software project is something professionals have known and argued for since the 1960s.

> The fact that short iterations adding features incrementally leads to better outcomes for software project is something professionals have known and argued for since the 1960s.

And practiced by software professionals since the 1960s. For maintenance. Even for aviation and nuclear. But in those industries, you're going to have a clear case, better documentation, and not be trying to "sprint."

Again, many truly best practices well predated XP/agile, and were subsumed into it. The real problem with XP/agile is the dogmatic straw-manning and demonization of other good practices that have their place, such as waterfall and exploratory programming. YAGNI, in particular, is more often used as a cudgel to shut down useful learning and exploration than anything else.