This was my gut reaction to reading the description of this book, but I'd like to see it before I pass judgement. There's certainly something to be said for "getting things right in the first place", but inventing a new word for design-up-front just seems like a silly attempt to sell the agile crowd yesterday's fish. This blog entry is a little disingenuous, though, too: while it's true that the term "refactoring" is often abused, it's often said that in XP you do continuous design. Whether you call design changes "refactoring" or whether you call it something else, it's still design change, and it's still something you have to do on a regular basis. Where's the boundary between design change and refactoring? 15 minutes? A half-hour? And don't forget that Fowler's book has a whole chapter near the end, co-authored with Kent Beck, called "Big Refactorings," all about design changes -- mostly of the "refactoring to patterns" variety.

I'm rambling, but my point is that although this book looks designed to still up controversy, the premise is not utterly off-base. I'm still interested in having a look.