Reading Jason Baker's thoughts on the issue, here is my response:
Personally, I've been pondering duck typing vs interfaces for a while. It seems that the choice is between a catch-all (duck typing) and a square hole (interfaces). Interfaces are great for static languages, but are more restrictive at design time than going for duck typing. At the same time, duck typing means that an increasing number of tests are needed to make sure the system copes with different usage.
But what if we restrict ourselves to web services? A datastream (MIME, xml, etc) is passed in, and the service provider has an SLA contract for expecting it to 'work'. But since we're dealing with externally supplied input, we do all our input-checking at the start, to make sure it's all sanitised. After that, we have effectively already done the checking we need (if we've done it well).
Now, do you take the static+interface approach, because you already know what the input is like, or do you take the duck-typing approach, because we've already sanitised the input, and have our TDD tests aligned with our input sanitisation?
My answer would be to go with duck-typing here. If we've defined our SLA well, we have excluded non-compliant input data, which will be turned down at the point of reception into the system. Thus we can dispense with the overheads of interfaces, since we can (Atwood style) throw hardware at the interpreted language speed issue.