In The Abstract
In Under the Radar #37, David and Marco discuss code reuse, and the benefits of abstraction. They come down solidly on the side of YAGNI — You Ain’t Gonna Need It. In other words, it’s usually not worth putting extra effort into making something more general than it needs to be right now, as you’re unlikely to correctly predict the way in which it will need to generalise (if it ever does).
This is certainly not a straw man; it’s a trap I’ve often seen people fall into, myself included. However, I’ve also seen people go too far in the opposite direction, viewing any abstraction or generalisation as a problem.
This made me look at my own use of abstraction, and I found myself thinking of the Field Notes brand tagline:
“I’m not writing it down to remember it later, I’m writing it down to remember it now.”
Similarly, I tend not to create abstractions to cope with future cases, but in order to understand the code that’s already there. Some people understand things best when they’re concrete and explicit, but I’m not one of them. I need to systematise things, to put them in a framework and create rules. This is one of the reasons I’m attracted to programming. The framework I construct to understand isn’t just a model of something; it can be the thing.
Abstraction, of course, can have numerous other benefits — brevity, clarity, and yes, even reuse. For me, though, it’s first and foremost a tool for understanding what the hell’s going on.