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

281–290 of 375 posts

Re: Prefer duplication over the wrong abstraction (2016)

#281

Post by jbeninger »

dofm wrote: post #227
jbeninger wrote: post #162

Earlier quoted context omitted.

The gold standard is code samples. I've got 1000-line convention documents with very simple rules like "Early returns on a single line". Llms sometimes ignore these or misinterpret them in unusual ways. But if I tell it "read these files that use the same conventions" first, there's no misunderstanding, and the agent also picks up the general "tone" of the code. I have very little to tweak if I've defined the problem…

> But if I tell it "read these files that use the same conventions" first, there's no misunderstanding, and the agent also picks up the general "tone" of the code. I have very little to tweak if I've defined the problem well. Oh that is a bloomin' great idea, and I can fully see how it might work better. Can't tell you how valuable this comment has been to me and now I feel so much better about evidently kicking a ho…

Glad I could help. I've been trying to use coding agents more than makes sense this year to get a feel for the tech. There's no good set of guidelines yet and everything feels like secret knowledge.

If you're using a coding agent like codex or claude code, I've also seen marked improvement by telling the agent to keep a journal of decision points, and every file read or written. And then, here's the important part, read the last five journals before starting. It primes the context with whatever you were working on and keeps a new session more focused that if it has to go searching for keywords through the whole codebase. It can also be an interesting read.

Re: Prefer duplication over the wrong abstraction (2016)

#282

Post by the_af »

robotresearcher wrote: post #232
the_af wrote: post #202

Earlier quoted context omitted.

This is something I've seen repeated time and time again as a criticism of (misused) abstraction and DRY, yet I've never seen ONCE -- and this is not hyperbole, I mean it literally -- a junior making an abstraction with any thought to reuse, generalizing anything, or caring about not repeating code. Most juniors I've worked with are content to just churn new code without paying attention to the codebase at all. This…

In the early 2000s I often saw juniors and students make staggeringly deep class hierarchies. The equivalent of: Shape::Polygon::ConvexPolygon::FourSidedConvexPolygon::Square::BlueSquare... "Intro to OOP" lectures/articles made a deep impression on some people in not quite the right way :)

I was working at that time and never saw this from juniors. Overeager seniors and architecture astronauts, sure. But juniors? They mostly copy pasted code without even taking a second look at the codebase, and without bothering to break functions in any sensible way.

Mind you, I mean enterprise and line of business software, not hobbyists. I also mean of their own volition, not the kind of nonsense that Java frameworks often forced on them (all the patterns under the rainbow, factory abstract method factory of abstract methods).

Re: Prefer duplication over the wrong abstraction (2016)

#283

Post by coldtea »

cjfd wrote: post #157
coldtea wrote: post #143

Earlier quoted context omitted.

Duplication is just code doing the same thing in several places, and as such it's much easier to make DRY (and much easier after you have N copies to see what should be shared and what should not), compared to re-architecting the whole system to remove a bad abstraction.

No. The duplication is seldomly that clean. It has started to diverge in subtle ways where the question becomes whether that was the intention or not. In the worst possible cases it has resulted in 8000-line functions full of duplication. 're-architecting the whole system to remove a bad abstraction' sounds fear mongering. That never happens.

>'re-architecting the whole system to remove a bad abstraction' sounds fear mongering. That never happens.

Oh, it happens all the time.

Re: Prefer duplication over the wrong abstraction (2016)

#284

Post by dilyevsky »

stanmancan wrote: post #214
jonahx wrote: post #164

Earlier quoted context omitted.

> I believe that "single source of truth" is a principle that should always be followed Fundamentally, the article addresses cases where it's not clear yet how many sources of truth there will be. Are the two spots in the code using the same algorithm, or slightly different versions? More importantly, will they change for the same sorts of reasons? The title adage (correctly, imo) argues that making two different thi…

The issue with not having a single source of truth is not the fact that you have to update code in 2-3 places, it’s that you have to know to update code in 2-3 places. Accidental divergence is the problem, not intentional.

Seems like this is a problem almost entirely solved by llm+vector database setup.

Re: Prefer duplication over the wrong abstraction (2016)

#285

Post by nextaccountic »

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…

The trouble with the wrong abstraction is that sometimes you really do want to change one and not the other. It's code that superficially look the same, but only temporarily (taking a snapshot at the current time) - they are meant to be distinct in the long run

Re: Prefer duplication over the wrong abstraction (2016)

#286

Post by codr7 »

I certainly learned this the hard way.

When I started writing code 40 years ago, I used to over estimate my understanding and abstraction skills a lot. As a result I created overly complicated and difficult to maintain/evolve solutions.

Turns out I need to see more examples of patterns before making good choices, which means becoming comfortable with seeing and tracking duplication over time.

Re: Prefer duplication over the wrong abstraction (2016)

#288

Post by jamiejquinn »

lg5689 wrote: post #55

I believe that "single source of truth" is a principle that should always be followed. If there's duplicated code where it'd be a bug if they diverge, then you should refactor. It creates a long-distance coupling in your code that may be invisible to future developers until a bug emerges. But with that in mind, I mostly agree with the article: if it's not a violation of "single source of truth", then abstractions are…

> it'd be a bug if they diverge

That's a very nice rule of thumb. I've often overabstracted when two pieces of code look similar at one point in time and then they diverge.

Re: Prefer duplication over the wrong abstraction (2016)

#289

Post by codemog »

ultim8k wrote: post #42

Nobody wants to listen. Nobody. In 90% of the companies there are some so called senior devs that get ecstatic when they create a new abstraction. Overengineering, abstractions and premature optimisation are the 3 worst plagues of engineering. At the same time I’m happy they exist because it means we’ll always have a job.

Yep Kubernetes, more micro services than engineers, some complicated protocol that saves a few bytes of overhead, cloud everything, and tons of classes that could have been simple functions.

Re: Prefer duplication over the wrong abstraction (2016)

#290

Post by ytoawwhra92 »

jonahx wrote: post #243
stanmancan wrote: post #214

Earlier quoted context omitted.

The issue with not having a single source of truth is not the fact that you have to update code in 2-3 places, it’s that you have to know to update code in 2-3 places. Accidental divergence is the problem, not intentional.

Yes, this is true. And is a bigger problem on large teams. One mitigation is a comment by the original author at both sites that there may be a coupling in the future. But, again, the point is that you don't know yet whether you have a single source of truth or not. It's a question of the relative badness of duplication vs premature abstraction in cases where the code may diverge or converge in the future . There is…

For pure logic I find refactoring to enable divergence much easier than implementing convergence.
Post reply on HN