Believing Abstractions

By nature or nurture, programmers fall into two camps regarding their general attitude towards abstractions: Believers and Non-Believers.

Another way of seeing the difference:

Of course, the truth lies in between...

{Contributors: FalkBruegmann, PanuKalliokoski, ...}

Some people like to take things apart to figure out how they work. It is often part of the "geek gene". Perhaps such people should find jobs closer to the hardware, such as embedded devices.

Actually, taking apart a well-built system of abstractions can be just as fascinating as taking apart any other system. One just has to get used to "Compartmentalizing", treating areas of abstraction that you haven't opened yet as little black boxes that do exactly what they say they do. (Or, alternately, starting from the edges/bottom and working your way out of the little black boxes and into the higher-level abstractions) This technique is, in my admittedly somewhat limited experience, amazingly effective when tracking down weird bugs in software. I have occasionally encountered a personal StackOverflow when doing this, but that's usually a sign that I'm trying to go too fast or skipping steps.
I'm not sure "belief" is the appropriate way of framing this, as if it's a mere matter of opinion. It strikes me that a) the world is too complex, and even such a simple thing as a computer program easily gets too complex, to be understood properly without a skill at abstraction; but b) AllAbstractionsLie, so you still need a skill at drilling down into details.

I wasn't perfectly happy with "belief/believer/non-believer" for the two approaches myself, just couldn't think of any better alternatives. Any suggestions?

About b): Yes you need a skill at drilling down, the question is just when you do it: immediately, because you mistrust the abstraction, or lazily on a per-need basis. About a): Yes, good programmers especially in the OO or functional world need also be good abstractionists. But let's just say that such skills are varied (try handing your average Lisp or AspectJ program to the average PHP guy...). Also, some people *can* deal with a higher level of abstraction if they have to, but are not comfortable at that level. --FalkBruegmann

I think that the ability to work with abstractions is more a skill than an act of faith. Of course, when working with poorly-formed abstractions, one's faith in them can quite rightly be shaken.

I like to say "Abstraction Is Power," implying that achieving higher levels of abstract understanding of a problem gives one leverage to accomplish more.

However, sometimes you do have to look at implementation characteristics -- for performance optimization, for instance. -- JeffGrigg
I fall into the "believer" category defined above, but I don't think of myself as BelievingAbstractions. I think of it as being optimistic. If an abstraction says it will do something I hope it does just that (and nothing more) but I feel safer with some tests to verify it. If the tests expose a lie I fix it, rename it, or (if I can't edit the source) wrap it. -- EricHodges
BelievingAbstractions is knowing that something written will DoAsItSays. It is not about being optimistic - when symbols DoAsItSays belief is unnecessary. In so much as AllAbstractionsLie: humans fall short in summing up the world around us with symbols; abstractions afford us Wiggle Room.
It seems to me that the correct way to go is to believe the name if it gives you enough information, and go read the code if it doesn't. Because of that, both clear structuring of code (i.e. no RavioliCode) and self-describing names are important. I'm more on the non-believer side, but believers still tend to write much longer methods / functions than I. -- PanuKalliokoski
It is partly a political issue. If you use somebody else's abstractions, but you take the heat if they fail, then most would rather reinvent or open them up. On the other hand if you can safely point a finger at the abstraction maker if it fails, then you are more likely to rely on it. -- top
I think I would try a slightly different categorization; general code reading versus program maintenance (two types).

The three viewpoints might be summarized as: Any reactions to this breakdown? -- WayneMack
Trust, but verify. If a library/framework is well-designed, I shouldn't have to read through its source in order to use it, but I find that if I do have some understanding of how the innards work, it helps me use it more effectively and efficiently. Sometimes a walk through the source code reveals things about the library developer's intent that don't get adequately communicated in the docs. -- MikeSmith
See Also: AllAbstractionsLie, EverythingIsRelative

View edit of July 10, 2010 or FindPage with title or text search