[kristov]

Abstraction is not just about hiding code - its about reducing options. You purposefully reduce options to make the system easier to reason about. A "function" in a programming language is an abstraction over machine code. It looks like variables have scope in an isolated environment, and it looks like the braces mean something, but it's compiled down to machine instructions that have no such concept. Goto considered harmful, but compiled machine code is littered with jump instructions (of course). You can do a lot of funky tricks with machine code that the higher abstraction of a programming language doesn't let you do. When you create an abstraction you reduce options for the user of that abstraction. So abstractions tend to gather cruft over time because users want those restrictions relaxed to do their special thing.

[feoren]

Absolutely right. One of the most important questions to ask an abstraction is: what can I not do with this? If the answer is "nothing -- you can do everything you could before", then the abstraction is an inner platform. The entire power that abstraction brings is in "focusing" on the problems we care about solving; it must make other problems impossible (ideally ones we don't care about). It follows from the No Free Lunch theorem.

One way to make sure your abstractions are focused on solving the right problems is to always define them based on what you need, not based on what you have. The root of the abstraction vs. duplication debate comes down to this. Indeed it's unhelpful to look at two pieces of code and say "these look the same; I will abstract them!". Instead you say "wow these have really similar needs; I will define exactly what that need is and they'll both ask for it."