In particular it was an epiphany about the YAGNI and DTST rules. I always assumed, based on the examples that were given, that the rules were meant to say "keep it simple, because that's probably good enough anyway". In other words, if you are sure that the simple approach isn't going to work, if your customer requirements include stuff outside the scope of the simple solution, you should use a more complex solution until you can encompass all the requirements. It should be no more complex.
Ward seems to be saying that this is wrong: that the goal is not to arrive at the simplest correct solution, but to arrive at the simplest solution that moves you forward, even if you know it's wrong. In fact, especially if you know it's wrong. Because you're going to arrive at the wrong answer multiple times anyway, it's very important that those answers be simple. Even if you can see deficiencies in your solution as you're implementing it, it's better to complete it quickly, put it in front of a customer, and determine experimentally whether the deficiencies you've spotted are as important as those the customer spots.
What I'm taking away from this article is that the key thing is release velocity, not correctness of the implementation or completeness of requirements analysis. The customer will change their mind. The estimates will be wrong. The only way you can compensate for this is by making changes cheap. The only way to make changes cheap is to practice making changes, and the only way to get practice is to make a lot of changes.
Being a drinker of XP kool-aid for quite some time now, it's funny how this still seems so counterintuitive to me. Looking at it sideways, though, it's a really distilled worse-is-better, with a much more narrowly-defined definition of how to "win big".
So, what do you think? Does "you have to do it wrong before you can do it right" sound like an accurate aphorism, or am I distorting Ward's words?