Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Prefer duplication over the wrong abstraction (2016)

sandimetz.com

Post reply on HN
Print view View original

101–110 of 375 posts

Re: Prefer duplication over the wrong abstraction (2016)

#101

Post by feoren »

fny wrote: post #35
dofm wrote: post #25

No it's not. This has always been a needlessly iconoclastic rather than sensible suggestion. At the very least it is not once you're working at the wrong kind of scale. Once you have an awkward number of customers (more than five and less than a hundred), maintaining duplicated code that should have been abstracted and modularised will only seem cheap if you don't mind that you burn through even junior employees at a…

Code duplication is cheaper than the wrong abstraction. If you have a good abstraction, you should run with it. If you haven't figured out a good abstraction at 5-100 customers, God help you.

A good abstraction? As in one? I'd go so far as to say the process of discovering and refining abstractions is the most important part of software engineering. A large project has dozens of abstractions, and some of them are "wrong" at any time, as you discover over time. None are ever perfect. If you wait to stop duplicating code until you have the "right" abstraction, you are just putting off the hard part of developing software and taking on tech debt.

Half of your abstractions are wrong. The hard part is knowing which half.

Re: Prefer duplication over the wrong abstraction (2016)

#102

Post by enos_feedler »

fny wrote: post #35
dofm wrote: post #25

No it's not. This has always been a needlessly iconoclastic rather than sensible suggestion. At the very least it is not once you're working at the wrong kind of scale. Once you have an awkward number of customers (more than five and less than a hundred), maintaining duplicated code that should have been abstracted and modularised will only seem cheap if you don't mind that you burn through even junior employees at a…

Code duplication is cheaper than the wrong abstraction. If you have a good abstraction, you should run with it. If you haven't figured out a good abstraction at 5-100 customers, God help you.

What if there is no good abstraction for the entire stack of software on each of computers? What if we built a common one because we had to? What if now we get to all make our own with natural language?

Re: Prefer duplication over the wrong abstraction (2016)

#103

Post by dofm »

davidee wrote: post #93
dofm wrote: post #63

Earlier quoted context omitted.

> Maintaining the wrong abstraction, or, god help, abstractions, would be even worse. Hard disagree. When you've had to chase through a change in untold and actually unknown numbers of duplications of code in different permutations and fix them because they are all on fire simultaneously, you'd disagree too. A bad abstraction would at least have had one fire in one place.

Good faith question: would it? Wouldn't most large codebases with poor abstractions just have engineers engineer around them with their own solutions? In a large enough codebase you'd have both the bad abstractions and all the not-quite-duplicate implementations ignoring the bad abstraction? I'm using bad here loosely, it could be buggy, incorrect, incomplete, insufficient and more; while being owned by someone or so…

> Wouldn't most large codebases with poor abstractions just have engineers engineer around them with their own solutions?

Obviously, yes. But it is my experience that this happens more slowly and that API invocations that break when the abstraction is changed are much easier to identify than broader duplicated patterns of code that span many lines and subtly diverge.

And even then those divergences are better because each wrapper around the abstraction is documenting the problem with it. But the abstraction can generally be replaced by one with the same API surface.

(Even if you take into account the fact that any API behaviour ultimately gets relied upon even if undocumented. Which is true.)

To be fair my experience is that of a freelancer and contractor who arrives trying to fix things that have been through many such hands. And I think if these developers had it drummed into their head that any attempt at abstraction would be better than copy and paste, these situations would be more knowable.

Re: Prefer duplication over the wrong abstraction (2016)

#105

Post by wonnage »

dofm wrote: post #85
agumonkey wrote: post #65

Earlier quoted context omitted.

You seem to have experience, I dont mind factoring / unifying logic, when done sensibly with enough history in the trenches. It pains me more whenever a young dev comes in and barks "we must merge these two things!" repeatedly without planning for more than two cases and starting to add more and more boolean variables. Crystal makers. Then the obvious issue comes, the two variants weren't that close and now there's o…

> I agree that LLMs are naturally anti abstraction machines.. I'm often trying to find way to reverse that. I am a bit of an LLM cynic but I am trying to learn it all, and I have to say I have spent most time trying to work out: how do you explain how a brown-field codebase actually works, in such a way that the LLM won't pervert it through misunderstanding. It does encourage you towards the "conventional" coding sta…

They don’t have a useful belief system, one of the rookie mistakes of using LLMs is asking them what you “should” do

Re: Prefer duplication over the wrong abstraction (2016)

#106

Post by omoikane »

> Programmer A sees duplication.

This step should also be parameterized by how many times the duplication has occurred. Refactoring preemptively may lead to poor abstractions, but not refactoring after seeing the exact same thing tens of times would also be weird. See also:

https://wiki.c2.com/?DuplicationRefactoringThreshold

https://wiki.c2.com/?ThreeStrikesAndYouRefactor

Re: Prefer duplication over the wrong abstraction (2016)

#108

Post by chairmansteve »

shinycode wrote: post #84
coldtea wrote: post #47

Earlier quoted context omitted.

Hardly iconoclastic, it's a very sensible suggestion. It would be iconoclastic if the common sense basic approach would be to start with abstraction. It's not, the common sense default is to write possibly duplicate behavior until you actually discover several cases to abstract away, until you bevalop a sensible idea of which functionality unites them and which doesn't carry over all of them. > Once you have an awkwa…

At work there’s been a huge number of duplication in the start of the company and no solid abstraction. So no tests as well. We introduced tests in the current architecture but rewriting code has a huge cost to make sure there is no regression. When we talk about a saas it’s non-trivial with many customers relying on this tool daily as part of their workflow, regressions because of rewrite could be really painful for…

"It’s hard to find a good balance and it depends on the kind of business and scale of project".

Exactly. The abstraction purists are not working in the messy, dead line driven real world.

Re: Prefer duplication over the wrong abstraction (2016)

#110

Post by coldtea »

dofm wrote: post #63
coldtea wrote: post #47

Earlier quoted context omitted.

Hardly iconoclastic, it's a very sensible suggestion. It would be iconoclastic if the common sense basic approach would be to start with abstraction. It's not, the common sense default is to write possibly duplicate behavior until you actually discover several cases to abstract away, until you bevalop a sensible idea of which functionality unites them and which doesn't carry over all of them. > Once you have an awkwa…

> Maintaining the wrong abstraction, or, god help, abstractions, would be even worse. Hard disagree. When you've had to chase through a change in untold and actually unknown numbers of duplications of code in different permutations and fix them because they are all on fire simultaneously, you'd disagree too. A bad abstraction would at least have had one fire in one place.

>A bad abstraction would at least have had one fire in one place.

On the contrary: that's precisely what a bad abstraction would not offer.

Instead it would spread its assumptions to different parts of the system, as every caller, sub-service, etc. would have to change shape to fit in that abstraction's box, however unnatural it is (and we know it would be unnatural, because we already said it's a bad abstraction).

Abstraction is not the same as encapsulation.

Post reply on HN