5 ms·

Same with Clean Code, SOLID, DD SOLID is especially funny because majority of developers doesn't understand / can explain it, let alone have read papers e.g [0

Same with Clean Code, SOLID, DD SOLID is especially funny because majority of developers doesn't understand / can explain it, let alone have read papers e.g [0], except maybe S letter, yet everybody acts like they do SOLID*. Or Clean Code's small function craziness or misinterpretation and going into "avoid comments" approach * - unless you ask for details [0] - https://www.cs.cmu.edu/~wing/publications/LiskovWing94.pdf https://www.cs.cmu.edu/~wing/publications/LiskovWing94.pdf

charles_f 5y ago
So the only caveat I would put on that: it's useful to have common language for things, my threshold is that you understand why things are this way. It's useful to tell someone: "you should have that thing in another class because it's clearly another responsibility", and have a debate on the responsibility itself ; or even on the merits of having a single responsibility per class. What is not useful is when someone will start making monofunction classes that are 10 lines long on the hotel of "smaller functions are better" and sticking to that because "it's a best practice" with no better argument. Basically my point is: if you understand what you are doing, great, use vocab all you want. But don't use it as a justification.
- RNCTX 5y ago
  Or, common language comes with some assumptions. Lots of people in software use lots of marketing terms as descriptions of the practice of their work. This is the crux of this conversation, actually: that absent "best practices" rooted in enforced standards, they're all really just marketing terms until proven otherwise.
tdeck 5y ago
Interesting, I guess SOLID must have been a buzzword from an earlier era, because while I've vaguely heard of it I had to look it up. Don't think it's come up in my 8 years of professional work. There's always an evolution of these methodologies and I often feel like in practice they're just a way to mix things up and make code health feel more interesting to those involved. Often people know there are problems with the design of their system, but they can't get buy in to fix them. These methodologies provide some authoritative justification for refactoring work.

charles_f 5y ago

So the only caveat I would put on that: it's useful to have common language for things, my threshold is that you understand why things are this way. It's useful to tell someone: "you should have that thing in another class because it's clearly another responsibility", and have a debate on the responsibility itself ; or even on the merits of having a single responsibility per class. What is not useful is when someone will start making monofunction classes that are 10 lines long on the hotel of "smaller functions are better" and sticking to that because "it's a best practice" with no better argument. Basically my point is: if you understand what you are doing, great, use vocab all you want. But don't use it as a justification.

RNCTX 5y ago
Or, common language comes with some assumptions. Lots of people in software use lots of marketing terms as descriptions of the practice of their work. This is the crux of this conversation, actually: that absent "best practices" rooted in enforced standards, they're all really just marketing terms until proven otherwise.

tdeck 5y ago

Interesting, I guess SOLID must have been a buzzword from an earlier era, because while I've vaguely heard of it I had to look it up. Don't think it's come up in my 8 years of professional work. There's always an evolution of these methodologies and I often feel like in practice they're just a way to mix things up and make code health feel more interesting to those involved. Often people know there are problems with the design of their system, but they can't get buy in to fix them. These methodologies provide some authoritative justification for refactoring work.