Saturday, October 18, 2014
Saturday, July 26, 2014
_I originally wrote the following for my Chainline Newsletter, but I continue to get tweets about this idea, so I'm re-publishing the article here on my blog. This version has been lightly edited._
I've been thinking about the consequences of the "wrong abstraction." My RailsConf 2014 "all the little things" talk included a section where I asserted:
duplication is far cheaper than the wrong abstraction
And in the summary, I went on to advise:
prefer duplication over the wrong abstraction
This small section of a much bigger talk invoked a surprisingly strong reaction. A few folks suggested that I had lost my mind, but many more expressed sentiments along the lines of:
The strength of the reaction made me realize just how widespread and intractable the "wrong abstraction" problem is. I started asking questions and came to see the following pattern:
- Programmer A sees duplication.
- Programmer A extracts duplication and gives it a name.
This creates a new abstraction. It could be a new method, or perhaps even a new class.
- Programmer A replaces the duplication with the new abstraction.
Ah, the code is perfect. Programmer A trots happily away.
- Time passes.
- A new requirement appears for which the current abstraction is almost perfect.
- Programmer B gets tasked to implement this requirement.
Programmer B feels honor-bound to retain the existing abstraction, but since isn't exactly the same for every case, they alter the code to take a parameter, and then add logic to conditionally do the right thing based on the value of that parameter.
What was once a universal abstraction now behaves differently for different cases.
- Another new requirement arrives.
Another additional parameter.
Another new conditional.
Loop until code becomes incomprehensible.
- You appear in the story about here, and your life takes a dramatic turn for the worse.