Abstraction Wrangling

Corey Haines blogged today about the difference between Taking it too far vs Taking too much time. He’s talking about refactoring, and the differences between beginners and more experienced programmers when refactoring (or choosing not to refactor).

One of his observations is that refactoring often involves introducing (or improving) abstractions. He says one differentiator between experienced programmers and beginners is that the more experience programmers have become more adept at “abstraction wrangling.” I think this observation is very apt; it tracks with what I’ve observed in teaching Java to inmates at Marion Correctional Institute. I think part of the reason for this must simply be the relative noise-to-signal ratio imposed by unfamiliarity with tools, conventions, TDD and the language being used. Less attention is available for thinking about abstractions when navigating the tools requires more conscious thought.

But another thing that makes abstractions relatively more difficult for beginners is simply understanding what they mean (or could mean) in the context of a computer program. Clearly, an object “joel” of type Person isn’t actually a real, live person. The implication is that the object “joel” has certain characteristics which model a real person. But in what sense is it true that “joel” is like Joel? In order to understand the computer program’s abstraction, it’s necessary to understand the intent or purpose of the program. Is it a phone book? Expect “joel” to have a phone number, just like Joel does. Is it an org chart? Maybe “joel” has a Boss, or TeamMates or an ArmyOfMinions. (Real Joel does not have an army of minions.)

In short I think the abstraction differentiator comes down to better familiarity with various application types and problem domains. This knowledge helps to inform a programmer as to all the ways in which “joel” could be like Joel, and more importantly, the ways in which “joel” is likely to be like Joel. Knowing the intent of the metaphor makes it possible to narrow our expectations and thereby avoid taking the metaphor too far. If the program is a phone book, we don’t expect “joel” to have an instance of MedicalRecords or a collection of ChildhoodExperiences.