That said I strongly second his point about the value of keeping designs simple. And I have an interesting piece of evidence in support of it.
I just read http://www.amazon.com/gp/product/0321117425?ie=UTF8&tag=... and one of the "facts" that Robert Glass brings up is that a 25% increase in requirements results in a 100% increase in software complexity.
I put "facts" in quotes because the claim is only supported by one study and I have lots of questions around how one would define key terms like "software complexity". However based on experience I am inclined towards believing that something like this is true. If you further believe (as I do), that the source of the requirements doesn't matter, then adding internal requirements about design is going to result in complications.
As a result I am inclined towards simple, clean designs. I gladly introduce polymorphism, abstraction layers, and so on fairly frequently. But only if I see a concrete benefit from doing so. If I am not convinced that this piece of abstraction produces a net win within the context of this software solution, I don't do it.
(For the record I am not a software master by any means. In Zed Shaw's terms I'd be an expert, although early mentoring with the right person kept me from ever suffering from the love of complexity that he pastes all experts with.)