I recently had to deal with a part of a system I'm working on that makes heavy use of implementation inheritance. The class hierarchy was quite complex and from the top it looked like a clumsy ball of classes. It took me quite a while to figure out what was going on. Information was spread over the classes in the inheritance tree and information has been duplicated in different classes. To make things even worse, the programmer was using anemic domain objects with almost no behavior. I figured out that the part of the system could be redesigned to be much cleaner and more extensible using almost no inheritance. I always wonder about this inheritance thing. I've talked to people who insist that inheritance, often proposed to be a key concept of today's OO languages, must be good to achieve reusability and maintainability.
But if you look around, it's hard to come up with a real-world example for inheritance. The world is composed, not inherited. Almost every object you see consists of several smaller "objects" working nicely together. Objects can be rearranged and combined in different manners to form new, bigger objects. You can use a stone to build a house or as a bookend. The stone doesn't care. It's perfectly decoupled from it's environment. You may say that you've inherited properties from your parents but in fact you don't "extend" your mother. You extend nothing. You're mother and father gave you a "construction plan" for your body, the DNA. And this construction plan is itself tells other objects how to build and arrange the cells your body consits of (can you feel the patterns emerging?). Still no inheritance in OO sense.
The concept of inheritance is rather abstract. In most OO languages, you define types (Classes) and objects are instances of these types. A type can extend another type. This is probably why one can't easily come up with a real-world example for the inheritance concept. The world is untyped. And even more, it doesn't need these types. Why do programmers? There are prototype-based languages, like Self, which don't have classes at all. They just have objects. New objects are created by copying and customization of existing objects. If you copy an object, it keeps a reference to it's source object and delegates messages it cannot handle itself to this object. This mechanism is called DelegationInhertiance and I like to put the emphasis on delegation. I feel this approach is more Object Oriented than our usual languages like Java etc. In fact, these languages should be called Class-Oriented, not Object-Oriented.
What does this mean for programmers? Well, I certainly don't want to tell you what this means for you. For me, this means that I strive to build systems that consist of small and shy objects working together. I aim to follow the "tell, don't ask" principle. I try to avoid inheritance where I can and favor delegation. Strategies and decorators are often a more flexible replacement for inheritance. I use interfaces to separate the different aspects and concerns of objects. I try to use dynamically-typed languages whenever I can since they make life so much easier.