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

301–310 of 375 posts

Re: Prefer duplication over the wrong abstraction (2016)

#301

Post by throwaway2037 »

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.

The part that no one want to say out loud: Making boring technology decisions makes you job boring and does not help to build your resume. This is the core reason why over-engineering exists.

Re: Prefer duplication over the wrong abstraction (2016)

#302

Post by throwaway2037 »

mystifyingpoi wrote: post #186
cryo32 wrote: post #2

You can do both with microservices!

I get the joke, but in ideal world, in microservices, there is no such thing as code duplication across services. As a maintainer of a service, I should not give a crap about code present in some other service - it's some other team's code, why would I care? I don't have to even know that the other team exists. In big systems, it happens that I can't even feasibly know the existence of all the applications.

In [an] ideal world, in monoliths, there is no such thing as code duplication across subsystems.

Re: Prefer duplication over the wrong abstraction (2016)

#303

Post by throwaway2037 »

crazygringo wrote: post #154
lokar wrote: post #68

Earlier quoted context omitted.

I feel like the balance has shifted over the last 30 years, and is speeding up. Semi-automatic and fully automatic re-factoring has made dealing with duplicated code much faster, cheaper and safer. Changing abstraction is still high risk.

Isn't it the opposite? Automated re-factoring means you can refactor duplicated code only as long as it is exactly duplicate . Whereas the whole problem is that when somebody changes 3 out of 10 of the duplicate cases in a simple way that they are no longer exactly duplicate, and then somebody fixes a bug in one of the other 7/10 cases, they can update the bug across the 7 "duplicate" cases but they'll miss the 3 tha…

    > Automated re-factoring means you can refactor duplicated code only as long as it is exactly duplicate.
This has not been true in JetBrains' IntelliJ for more than 10 years. It can parameterize refactoring multiple blocks of code.

Re: Prefer duplication over the wrong abstraction (2016)

#305

Post by yCombLinks »

bhouston wrote: post #13

I used to struggle with abstractions back in my OOP days but since moving pretty much to a purely functional approach I find that code duplication is rare. Just have a function and call it in two parts. The main abstraction issue is then data structures but with TypeScript interfaces being duck typing essentially I run into few problems there as well. So code duplication because of abstraction issues is rare. Code du…

Not seeing how this makes sense in terms of the article? A function is an abstraction. Extracting duplicate code into a function is the same concept.

Re: Prefer duplication over the wrong abstraction (2016)

#306

Post by annzabelle »

ozim wrote: post #280
wellpast wrote: post #234

Earlier quoted context omitted.

Definitely the hallmark of junior. Obsession with code deduplication as the highest pri when it’s quite low among others.

Well I have seen a lot of „expert beginners” who have years of experience on paper but fight tiny duplications like their life depends on it. „How Software Groups Rot: Legacy of the Expert Beginner”. https://daedtech.com/how-software-groups-rot-legacy-of-the-e...

Thank you for this link.

I have recently fallen into a job at a small company that really seems to have this culture. Thankfully, I'm only going to be here for a year and a half or so (fixed term job for working holiday visa), but I'm trying to be really aware of how its impacting my career development.

There is no automated testing, no meetings, seemingly no code review process, no standardization of schemas for files that are passed between different applications, all jobs are run on on prem desktop workstations.

Re: Prefer duplication over the wrong abstraction (2016)

#307

Post by the_af »

throwaway2037 wrote: post #295
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…

Were you the same when you were a junior? I was. I didn't have the experience to understand the impact of my changes. The norm reply on HN: "You need more mentoring or code review.". Sometimes (usually?) that is in short supply.

Absolutely. I made all the usual mistakes, and had to be mentored and learn from more experienced programmers.

(Alas! Sometimes you pick up bad habits from experienced people, and being a junior, you don't know better)

Re: Prefer duplication over the wrong abstraction (2016)

#308

Post by skreem »

Nice to see Sandi mentioned! If anyone liked her philosophy / writing style I highly recommend you check out her books

I read “Practical Object-Oriented Design (POODR)” ages ago at this point, but it reshaped how I approached OOP

Granted… OOP as a default paradigm has fallen out of favor (at least for me), but it’s still everywhere & won’t be going away. She gives a great framework for making it sane

Re: Prefer duplication over the wrong abstraction (2016)

#309

Post by the_af »

throwaway2037 wrote: post #297
robotresearcher wrote: post #232

Earlier quoted context omitted.

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 probably that guy! It was all the rage 20 years ago, including worrying about the diamond inheritance problem. What is the equivalent in the current generation? ORM that no one can maintain? Unnecessary dev ops complexity? Anything "web scale"?

Are ORMs still a thing? I've been away from OOP for some years now, but just when I was leaving it, there was a trend firmly against ORMs... my guess was that they were on their way out, replaced by more lightweight libs and frameworks? Or did they make a comeback?

Regarding OOP itself, I also remember when "favor composition over inheritance" became a thing. Was this reversed too?

Re: Prefer duplication over the wrong abstraction (2016)

#310

Post by dbalatero »

the_af wrote: post #309
throwaway2037 wrote: post #297

Earlier quoted context omitted.

I was probably that guy! It was all the rage 20 years ago, including worrying about the diamond inheritance problem. What is the equivalent in the current generation? ORM that no one can maintain? Unnecessary dev ops complexity? Anything "web scale"?

Are ORMs still a thing? I've been away from OOP for some years now, but just when I was leaving it, there was a trend firmly against ORMs... my guess was that they were on their way out, replaced by more lightweight libs and frameworks? Or did they make a comeback? Regarding OOP itself, I also remember when "favor composition over inheritance" became a thing. Was this reversed too?

> Regarding OOP itself, I also remember when "favor composition vs inheritance" become a thing. Was this reversed too?

I think this is generally still the advice, when working in OOP contexts.

Post reply on HN