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

Prefer duplication over the wrong abstraction

sandimetz.com

Post reply on HN
Print view View original

11–20 of 101 posts

Re: Prefer duplication over the wrong abstraction

#11

Post by christophilus »

menzoic wrote: post #7
vemv wrote: post #2

And conversely, the right abstraction is preferrable over duplication. There's almost always chance to stop a little, think/research hard and create something novel, maybe leveraging specific features your language/framework offers.

Duplication is fine until it gets out of hand, at which point you'll be able to identify the right abstraction.

Yeah. I'd agree with this. I've had to maintain some terrible codebases with duplication everywhere. The truth is, I have an easier time fixing bugs in simple but duplicated code than I do fixing bugs in super abstract but DRY code. Which has me thinking: clear, obvious code with duplication is better than magic code which is DRY.

Obviously, the best is DRY, obvious, and explicit...

Also, a rule of thumb is premature optimization is bad. So is premature abstraction.

Re: Prefer duplication over the wrong abstraction

#12

Post by corecoder »

js8 wrote: post #3

How do you know that the abstraction is wrong (and how) if you don't create it? It seems to me like the article is saying - don't ever make mistakes, they are costly.

Not that I am that good at following her advice, but: you have to look at your code in a more dynamic way; you try several designs, thus several abstractions, and you know which abstractions are bad because they don't work for you at solving the problem at hand. That and some generic rules of thumb, like: prefer composition over inheritance.

Re: Prefer duplication over the wrong abstraction

#13

Post by js8 »

nerdponx wrote: post #5
js8 wrote: post #3

How do you know that the abstraction is wrong (and how) if you don't create it? It seems to me like the article is saying - don't ever make mistakes, they are costly.

I think the point of the article is that, if you aren't totally sure that an abstraction is correct or justified, then it's better to avoid building one in the first place. Not saying to never make mistakes, it's highlighting a particular kind of mistake that people don't always think about, and suggests that you can avoid making this mistake by not being so obsessive with DRY

I think such conservative approach can be justified when working on existing code, which has been somewhat proven to work. But I don't think it's justified when you're building the code.

I simply don't think you can always get the good abstraction right. But if you don't attempt it, you will never get it right. What you're advocating is not attempting it.

Re: Prefer duplication over the wrong abstraction

#14

Post by forrestthewoods »

Man I dunno. This is so tough.

On one hand, absolutely. Stacking params on params is a recipe for disaster. But often times with duplication you do need to update the duplicates. Which means you wind up with 6 pieces of code all similar but slightly different such that it fails in increasingly nuanced and edge casey ways.

No silver bullet unfortunately.

Re: Prefer duplication over the wrong abstraction

#15

Post by smailq »

This is another one of the factors that makes development time estimates difficult. While adding/removing/improving the code, you realize that some part of the code needs to be abstracted/duplicated, or vice versa. And this could take unknown amount of time to get it done.

Also, this is where the technical dept incurs over time, if the abstraction/duplication is held off.

Re: Prefer duplication over the wrong abstraction

#16

Post by swsieber »

This fits in very well with the concept write code that is easy to delete: http://programmingisterrible.com/post/139222674273/write-cod...

And here's the link to that discussion earlier this year: https://news.ycombinator.com/item?id=11093733

Edit: fixed the typo where I said wife instead of write.

Re: Prefer duplication over the wrong abstraction

#17

Post by adrianN »

menzoic wrote: post #7
vemv wrote: post #2

And conversely, the right abstraction is preferrable over duplication. There's almost always chance to stop a little, think/research hard and create something novel, maybe leveraging specific features your language/framework offers.

Duplication is fine until it gets out of hand, at which point you'll be able to identify the right abstraction.

Then you're in the situation that your code is a mess of copy-paste and its obvious what you should do, but management prefers that you work on features instead of changing "proven, reliable" code. Thus the mess is there to stay.

Re: Prefer duplication over the wrong abstraction

#20

Post by smcl »

nerdponx wrote: post #5
js8 wrote: post #3

How do you know that the abstraction is wrong (and how) if you don't create it? It seems to me like the article is saying - don't ever make mistakes, they are costly.

I think the point of the article is that, if you aren't totally sure that an abstraction is correct or justified, then it's better to avoid building one in the first place. Not saying to never make mistakes, it's highlighting a particular kind of mistake that people don't always think about, and suggests that you can avoid making this mistake by not being so obsessive with DRY

I think the point of the article is to catch eyeballs and get shared because "I'm pleased to announce that I'll be teaching a public Practical Object-Oriented Design course in San Francisco on May 9-11, 2016" ...
Post reply on HN