Comment by lostcolony | Hacker News Reader

Comment by lostcolony | Hacker News Reader

Parent Full thread

"It was good for something"

The post does seek out where the SOLID principles came from. And it's not really debunking them; just saying they're not absolutes. Which, yes, the title is click-baity, but I've certainly found people who treated them as absolutes, or tried to talk about code from SOLID perspective, and I've certainly never found that useful.

In fact, I've not found -any "best practice" to ever be absolute in a generalizable sense, and it's never been useful rhetoric to bring them up in a design discussion because of that. In fact, they sometimes run counter to each other. "DRY would say we should combine these together" - "Yeah, but Single Responsibility; while the code is mostly the same, they fundamentally are dealing with different things in different contexts".

Learn the heuristics, then deal with the subjective realities each project brings; anyone who tries to treat a given codebase as having an objectively correct approach, rather than a nuanced and subjective series of tradeoffs, is not someone worth talking or listening to.

> "DRY would say we should combine these together" - "Yeah, but Single Responsibility; while the code is mostly the same, they fundamentally are dealing with different things in different contexts"

As originally coined, DRY speaks of ensuring every piece of knowledge is encoded once. If pieces of code are "dealing with different things" then those are two pieces of knowledge, and DRY (per that formulation) does not recommend combining them.

I agree that there is a prevalent notion of DRY that is more syntactic, but I find that version substantially less useful and so I try (as here) to push back on it. Rather than improving code, it's compressing it; I've joked that we should call it "Huffman coding" when someone tries to collapse unrelated things in ways that will be unmaintainable.

Note that it's not just that syntactic DRY sometimes goes to far - it also misses opportunities where the original DRY would recommend finding ways to collapse things: if I'm saying "there's a button here" in my HTML and in my JS and in my CSS, then I'm saying the same thing in three places (even though they look nothing alike) and maybe I should find a way to consolidate.

There are, of course, still tradeoffs - maybe the technology to unify the description isn't available, maybe deepening my tech stack makes things less inspectable, &c.

>>I've joked that we should call it "Huffman coding" when someone tries to collapse unrelated things in ways that will be unmaintainable.

heheh I've made that joke too, also "let's un-complicate this into a pointless complexity," when its goes over their head.

I posted to a sibling comment to yours, but wanted to say here too - at that point it ceases to be a useful statement to ever bring up, because I've never seen a discussion where everyone agreed things were the same 'piece of knowledge', and one side was saying it should be repeated. When I've heard "DRY" trotted out, it's -always- been in a situation where the other side was trying to claim/explain that they were different pieces of knowledge. Hence my statement - it's worth understanding the meaning of the principle, internalizing the lesson, as it were, but then the formulation ceases to be useful.

Interesting. Our experiences differ dramatically.

In my experience, misguided "could this be DRYer" is usually motivated by superficial similarity, and a focus on knowledge is clarifying. (Although as I mentioned, "yes, it's repeated, but given tradeoffs that's the best in this case at least for the moment" is still possible.)

I understand that this is almost nitpicking (because the DRY example is not the point of your comment), but your DRY example is a really bad example of this, but rather a very good example of the lack of knowledge within the software community. According to Wikipedia, DRY means "Every piece of knowledge must have a single, unambiguous, authoritative representation within a system" [1], NOT to deduplicate all code that looks the same. It's actually more or less exactly the same as the Single Responsibility principle.

PS. Interviewing senior devs, team leads and tech leads atm. And so far none (!) have been able to properly formulate this (even after I'm hinting that it's not only about code deduplication) and 75-90% believe it's all about code deduplication. Imo quite scary, and tells you a fair bit about the shape of the software dev industry...

[1] https://en.m.wikipedia.org/wiki/Don%27t_repeat_yourself

>>none (!) have been able to properly formulate this (even after I'm hinting that it's not only about code deduplication) and 75-90% believe it's all about code deduplication

Well, duplicate code is the typical manifestation, as the sibling comment [1] relates:

>>> if I'm saying "there's a button here" in my HTML and in my JS and in my CSS, then I'm saying the same thing in three places (even though they look nothing alike) and maybe I should find a way to consolidate.

"and maybe" it's just otherwise hard to get the point across, as you've discovered. Isomorphisms are easier to distinguish (and validate!) versus homeomorphisms, but unnecessary pedantry usually results in MEGO. We shouldn't expect senior developers to automatically embody the virtues of mathematicians or philosopher-kings...

yeah, I am nitpicking worse, but after 40+ years in the industry and suffering through tens of thousands of marginally relevant distinctions in "gotcha" interview questions, I am without shame even though my head is nodding in acknowledgment of your points...

[1] oops, I meant https://news.ycombinator.com/item?id=26532424

I'm not really following you but intrigued. A few questions: You're quote of the parent doesn't seem correct? Where did you find that quote? MEGO?

This is imo not a gotcha interview question. It's A) Intended as a way for me to check if the person has an understanding of when to deduplicate code or not (I don't care if they know what DRY is, and I try to help them without giving them the straight up core part of the answer, give examples, etc). I believe this is one of the fundamental parts of writing maintainable code and B) Able to formulate this so that others can learn from them. Both are critical skills for the role.

In my experience, by applying DRY wrongly you're creating a really dangerous code base (maintainability wise). It's probably even worse to deduplicate code wrongly than not deduplicating at all.

>this is one of the fundamental parts of writing maintainable code

>It's probably even worse to deduplicate code wrongly than not deduplicating at all.

I strongly agree.

>A few questions: You're quote of the parent doesn't seem correct? Where did you find that quote? MEGO?

pardon me, I meant a sibling [1], not the parent comment. Otherwise I'm just relating my experience. MEGO is an acronym for "my eyes glaze over", I see searching on it leads to a LEGO clone, thanks Google. Trying to explain why a homeomorphism is potentially a DRY violation is the kind of explanation that leads to MEGO.

I don't like those "hinting" questions any more, in retrospect it seems more about exploiting assumptions of superiority at being obscure rather than a valid assessment of suitability. Also seems to waste precious time (interviews cost time, more valuable than money). Better to be direct and practical, principally because misunderstanding is more likely the default state of human transactions. It is probably better to first settle on a mutual understanding of some expected conceptual requirement (e.g. understanding of DRY), then produce some specific examples for the interviewee to judge and interpret. Since these are mostly heuristics, judgement with respect to application of heuristics is the key facility I would attempt to elicit, InMyHumbleOpinion (no more TLA, CamelCase from now on!).

[1] https://news.ycombinator.com/item?id=26532424

Well code is data, so it's understandable that things get squishy inside people's heads.

Yes, but at that point it stops being a heuristic and instead is a tautology. "Don't repeat the things that shouldn't be repeated". Or even what you said, which, again, is a nice statement, but who decides what 'a piece of knowledge' is? I.e., when is it the same bit of knowledge, vs when is it different? That's often the heart of it; I've had those debates (and in fact, was referencing them in my parent comment), where someone feels these ~things~ are basically the same, and so should be treated mostly the same, with shared code, and where someone else feels that, no, the differences are sufficient that they should be treated differently. And that's a reasonable discussion to have. But it's one that trotting out "Don't Repeat Yourself!" or SOLID or etc adds -nothing- to; the principles themselves clash, and ignore the core difference you're trying to work out.

In short, the reasons for the principle matter, but if you know to look for and understand the reasons, the principles themselves are obvious and do not serve as useful heuristics.

What is a piece of knowledge, who decidesn: A piece of knowledge in the domain. Of course there can be discussions around that as well, but should clear up the most obvious mistakes?

Principles and concepts: The reason for naming things is to be able to efficiently communicate things, make them memorable, etc? For example when communicating things in an interview? Why do we name things generally? Empire State Building? Or just the building on Xth street/avenue in NYC. Then of course, if everyone is misinterpreting the Empire State building for the Statue of Liberty then either the naming was off, or the teachings of the name....

Here's a very specific example I had -

A senior dev was creating an admin tool that took 7 or so different things, and treated them the same. They were very similar in how they operated, but there was some complexity.

Cue two months of MTTF never changing; squash a bug, introduce a new one.

I, as a junior, opted to rewrite everything. Got manager buy in. Did so, largely just separating these areas, treating them as unique things. Voila. MTTF started dropping.

Everyone agrees if it's the same thing, don't repeat yourself; no one thinks repeating themselves is a virtue. So once you understand that it's worth trying to find the things that are the same bits of context, knowledge, etc, as part of basic understanding of the domain, you understand the reasons for DRY, and the phrase ceases to need ever be uttered (and in fact, becomes counter productive, because it is to try and say "best practice would be to not repeat this!" without actually addressing the real issue at stake; are these the same thing?)

Reply on news.ycombinator.com