Many people apply DRY (Don't Repeat Yourself) dogmatically to avoid code duplication, but there's a real tradeoff to unifying multiple codepaths that have some shared logic but aren't fundamentally doing the same thing. Often better to repeat yourself 5 times; only then abstract.

Apr 20, 2022 · 11:02 PM UTC

21
26
10
328
Replying to @gdb
Also relevant: just because you solve a problem doesn't mean you don't refine it before you submit the solution. I see a lot of devs simply ship the first solution, when spending 5 more minutes on it typically drastically simplifies it.
1
3
Replying to @gdb
I'm waiting for DALL-E of this tweet
Replying to @gdb
There is definitely a danger in trying to abstract something too early
2
Replying to @gdb
AHA: avoid hasty abstractions
1
Thoughts like this come with time.
Replying to @gdb
The wrong abstraction is worse than no abstraction. Some times it’s worth it to do the work, repeat ourselves, and if needed take the lessons learned later on into an abstraction
1
3
Replying to @gdb
@unclebobmartin talks about this very well. the dry principle is misunderstood: duplicated code is code that looks the same AND changes for the same reasons; that's different than code that just looks the same.
13
Replying to @gdb
Indeed, especially when writing smart contracts. Better to be safe than sorry, best not to try and be too clever in this realm.
1
Replying to @gdb
I think the key principle is really, “What is going to change?” I gave a talk about this recently. gitlab.com/dahjelle/an-archi… Really a summary of David Parnas’ work. pauldee.org/se-must-have/par…
3
Replying to @gdb
My rule of thumb is to abstract only if changing one part forces all the other places to change as well. In that case, not abstracting leads to bugs because people forget to update all the places
3