4 ms·

More often than otherwise, I’ve found code duplication preferable over abstraction. I only abstract code when I understand the problem space really, really well

More often than otherwise, I’ve found code duplication preferable over abstraction. I only abstract code when I understand the problem space really, really well (I.e. have solved it before), or when I can have some certainty the wrong abstraction won’t cost me too much time to fix.

gfodor 7y ago
It does seem that this lesson takes at least a decade to internalize, and as such one can usually estimate the level of experience a person has based upon how much they embrace “DRY” as a hard rule vs a guidepost.
- ken 7y ago
  I've been programming for over 20 years, and I can't say I've ever regretted being too DRY. I'll take abstraction any day.
  - gfodor 7y ago
    Well, the pain you get from this is hard to peg as being due to over-DRYing, it manifests as bad abstractions, which are hard to trace the origins of.
smoe 7y ago
Agreed. Also one can get over-eager with abstractions over things that are not real duplicates. They just happen to look similar at this moment in time. In this category, I would also put premature automation before learning what it actually is you are automating among other things. Or more generally: Don't try to be clever about something you don't (yet) understand.
- chubs 7y ago
  I once read a guideline (by DHH I think?) "One, Two, Refactor" as in write it once, then duplicate it, and the third time think about refactoring it to be DRY. But yes it's all about discerning what's reasonable given the circumstances, and not being dogmatic.
codr7 7y ago
It takes time to build the kind of self confidence and humility it takes to allow a code base to sprawl for a while until you've seen enough examples to have an idea where it's going. The first thing I like to do is solve the problem, period. Without inventing anything, just simply write code to cover most cases. Then I'll start improving on it in small ways, cutting down on duplication and inventing abstractions; until I reach a tipping point where I can visualize a complete design, which results in a major refactoring. It looks messy in comparison to so called best practices, but it's faster and the code that comes out of the process is clearly better. DRY is hurting more than helping if you ask me; because it shames inexperienced developers into premature abstraction, causing plenty of pain and misery along the way.
- gpu_explorer 7y ago
  This. 1000x this.
doctor_eval 7y ago
Wasn’t it Fred Brooks who said, “Plan to write it twice, you will anyway”? I fell into the trap of premature abstraction yesterday: I spent an hour breaking down functionality to make it “easier” to implement different backends, only to realise that the “abstraction” was strongly coupled to the structure of the single backend I’d written. Young me would have forged on regardless because “abstractions”. Old me threw it away.
meestaahjoshee 7y ago
"duplication is cheaper than the wrong abstraction" i think i read that in POODR by sandi metz
- ngcazz 7y ago
  Her book with Katrina Owen “99 Bottles of OOP” lays out an even better case for this I think. Particularly useful is the introduced language to help measure the state of a codebase (“shamelessly green” vs “incomprehensibly concise” etc). Also quite like Fowler’s observation in Refactoring that (to paraphrase) abstractions are earned, not enforced.
thunderbong 7y ago
I try to follow the Rule of Three https://en.wikipedia.org/wiki/Rule_of_three_(computer_programming) https://en.wikipedia.org/wiki/Rule_of_three_(computer_progra...

gfodor 7y ago

It does seem that this lesson takes at least a decade to internalize, and as such one can usually estimate the level of experience a person has based upon how much they embrace “DRY” as a hard rule vs a guidepost.

ken 7y ago
I've been programming for over 20 years, and I can't say I've ever regretted being too DRY. I'll take abstraction any day.
- gfodor 7y ago
  Well, the pain you get from this is hard to peg as being due to over-DRYing, it manifests as bad abstractions, which are hard to trace the origins of.

smoe 7y ago

Agreed. Also one can get over-eager with abstractions over things that are not real duplicates. They just happen to look similar at this moment in time. In this category, I would also put premature automation before learning what it actually is you are automating among other things. Or more generally: Don't try to be clever about something you don't (yet) understand.

chubs 7y ago
I once read a guideline (by DHH I think?) "One, Two, Refactor" as in write it once, then duplicate it, and the third time think about refactoring it to be DRY. But yes it's all about discerning what's reasonable given the circumstances, and not being dogmatic.

codr7 7y ago

It takes time to build the kind of self confidence and humility it takes to allow a code base to sprawl for a while until you've seen enough examples to have an idea where it's going. The first thing I like to do is solve the problem, period. Without inventing anything, just simply write code to cover most cases. Then I'll start improving on it in small ways, cutting down on duplication and inventing abstractions; until I reach a tipping point where I can visualize a complete design, which results in a major refactoring. It looks messy in comparison to so called best practices, but it's faster and the code that comes out of the process is clearly better. DRY is hurting more than helping if you ask me; because it shames inexperienced developers into premature abstraction, causing plenty of pain and misery along the way.

gpu_explorer 7y ago
This. 1000x this.

doctor_eval 7y ago

Wasn’t it Fred Brooks who said, “Plan to write it twice, you will anyway”? I fell into the trap of premature abstraction yesterday: I spent an hour breaking down functionality to make it “easier” to implement different backends, only to realise that the “abstraction” was strongly coupled to the structure of the single backend I’d written. Young me would have forged on regardless because “abstractions”. Old me threw it away.

meestaahjoshee 7y ago

"duplication is cheaper than the wrong abstraction" i think i read that in POODR by sandi metz

ngcazz 7y ago
Her book with Katrina Owen “99 Bottles of OOP” lays out an even better case for this I think. Particularly useful is the introduced language to help measure the state of a codebase (“shamelessly green” vs “incomprehensibly concise” etc). Also quite like Fowler’s observation in Refactoring that (to paraphrase) abstractions are earned, not enforced.

thunderbong 7y ago

I try to follow the Rule of Three https://en.wikipedia.org/wiki/Rule_of_three_(computer_programming) https://en.wikipedia.org/wiki/Rule_of_three_(computer_progra...