This book started out great and indeed conveys a very good idea. But my resistance to it, perhaps most people's resistance to it, is its nonstop non-designer bashing, especially programmers. Every time I pick up the book lately, I tell my wife, "I'm trying to finish the programmer abuse book." According to Alan, we're all arrogant, passive-aggressive know-it-alls who have no clue about user interaction and only love new features and have no interest in making software easier to use.
Aside from the abuse, an irritating thing about the book is how dated all of his examples are. Though it's been revised recently, most of his computer software examples are from the 90's, an era approaching two decades in age. In fact, almost every complaint he posed, I could think of at least one software application that does "what he just wished they'd obviously do." Maybe everyone's read this book and implemented his idea... who knows. But he often comes off as a whiner and a doomsayer.
One obvious fact to be taken into consideration is that he works, nay, created a company that focuses on interaction design, so of course he's going to talk about how everyone else is incapable of doing the job right.
Of all the negative points I've made (maybe I'm just being an arrogant know-it-all programmer), the whole idea of interaction design sounds like a very good one, and could best be explained by his example in the last few pages: once upon a time, programmers thought they were the only ones who could reliably test their own code, but they hated it. Now (at least at my company), we have an entire QA role devoted to just testing software. Once that role was created, programmers didn't have to spend so much time doing something they hated, and others who actually liked poking and prodding software could do a better job. Alan is just suggesting something go on the other side of the development process and design the whole system fully before developers start on it.
I'll admit that sometimes I work hard to make something look or act in a very particular way that I think is 'good' or 'right' and take offense when it ultimately changes to something completely different. But as I enjoy problem solving, I really wouldn't mind having someone else take responsibility for that process and just let me do the technical work of programming it. Since we do focus a lot on design where I work, it's one of the most frustrating things to try to get everything nailed down before starting a project. If I were handed a blueprint, I could focus on what I'm good at technically - writing good code that performs well and excels at getting the expected job done.
If this book focused on that aspect instead of bashing everyone who has no clue how to do interaction design, the concept could take off like wildfire.