Boy oh boy, Jeff and I had fun videoing and editing this one: Duck typing.
Imagine that you have a function which expects a duck object. However in this method all that's really required is the Walk method of the passed in object, the Swim method and the Quack method. The function doesn't care if the object has a Bill property or a Feathers property or anything like that; it just wants to ask the object to Swim, Walk, and Quack. If the object can't do one of these things then a run-time error is raised.
In essence what's happening here is exemplified by the following saying: "if it walks like a duck, swims like a duck, and quacks like a duck, then I call that thing a duck."
Now you may say that duck typing is a little too dangerous to use. An example is a function expects an object with a Cleave method. In certain scenarios, Cleave may split something apart, and in others stick something together. The behavior changes according to the object passed in. In reality such issues are rare and can be avoided by proper testing.
The other thing to grasp is that duck typing is all about viewing object-orientation in terms of message passing, not about designing and implementing some class and interface model. It is ideally suited to a dynamic programming language with loose typing and provides a basic form of polymorphism without the verbosity and strict typing of an inheritance class model.
Not much more to say really. When objects are easy to create and configure (that is, without all the paraphernalia of a class model behind it), duck typing will be prevalent.
(You can watch the video here.)