9 ms·

I had to look up what SOLID is, and it kinda goes against most of what we’ve learned about software development since the 90s. When people say they don’t want a

by t8sr 3y ago

I had to look up what SOLID is, and it kinda goes against most of what we’ve learned about software development since the 90s. When people say they don’t want algorithmic “leetcode” interviews, I wonder if this is the alternative they want? 1999 style OOP Java trivia? Is the idea that you’re supposed to provide good discussion of the pros and cons, and so show some experience? That sounds like you’ll just hire people who had similar experience to you.

mytailorisrich 3y ago
Hmm, SOLID is very well-known and the principles are ubiquitous good practices for object-oriented programming and also useful for software dev in general. Certainly, asking about them and , especially, asking the candidate to critique them is a very good question.
- diarrhea 3y ago
  Only ones I ever found worthwhile are D and maybe I.
  - mytailorisrich 3y ago
    S (Single responsibility principle) is very important, not only for OOP but for good, maintainable software design in general (yes, even if you do firmware stuff).
    - diarrhea 3y ago
      Absolutely. I just find it rather inactionable, as it can be subjective.
      - mytailorisrich 3y ago
        Odd because that's arguably the easiest to apply when designing software.
  - tetromino_ 3y ago
    The only part of SOLID that is unquestionably correct is "L" - it is the only sane way to use subclassing in OO languages. "D", when used judiciously, can be useful because it can make unit tests much easier to write. But when used too much, it results in incomprehensible code. But as for "I", in my humble opinion, when you find yourself reaching for it, it's a sign that the code base is already poorly organized.
    - fhars 3y ago
      But the L part is only correct in so far as it repeats the definition of what it means to be a subtype, i.e. it is vacuously true. BY the way, does any OO language apart form Ocaml get this right?
      - ahtihn 3y ago
        The L part was apparently not so obvious to the authors of the Java standard library since it has violations all over it. Readonly implementations of java.util.List come to mind.
- t8sr 3y ago
  It’s well known in a specific setting, possibly? I’ve managed to never hear of it in 18 years. If asking “well known to some people” stuff is kosher, should I be able to quiz candidates on FFP design principles in Haskell, or maybe how to implement collision detection in a video game? Both of those are well known in swaths of the industry. I guess if you’re hiring for a specific role, writing OOP business applications, you will have no shortage of candidates who know about SOLID, but you’re probably passing on everyone who is changing domains.
- hajile 3y ago
  It’s generally not what it claims. Single purpose is a good idea, but the rest… The idea that one class changing won’t change others is a pipe dream. Substitution only matters if you’re using inheritance, but if you’re inheriting, you likely have bigger problems as few real world problems are naturally represented by inheritance. The interface rule is redundant with the single principle idea. Maybe it should have been SOLD instead. Dependency injection is a guideline at best. If you actually do what it says, you get enterprise fizzbuzz. It should only be used occasionally and sparingly at specific boundaries otherwise the cure becomes worse than the disease. More controversially, when you avoid inheritance in favor of composition in a language like Java, you lose polymorphism while keep a leaky abstraction and really bad encapsulation while the language still retains all the mental and syntactic complexity of the inheritance bits. https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...
  - mytailorisrich 3y ago
    > The idea that one class changing won’t change others is a pipe dream Reality is never black and white but that's a good principle for good software design and worth at least aiming for. If anything that has been adopted and generalised in microservices, etc. because encapsulation, modularity, design by contract all hinge of this same idea, which is powerful and useful. That's why when discussing any "principles" the important is to get the core idea behind them instead of sticking to the letter and discarding them as useless.
    - hajile 3y ago
      Encapsulation is extremely important and pairs with single responsibility, but that’s completely orthogonal to OOP. Once you are solidly in the composition camp, functions are immediately superior. They tend to be naturally single purpose and have mathematical rules that make them easy to compose. Most function-heavy languages also adopted modules which provide a better, less-leaky abstraction too and that’s without getting into all the other advantages in the type system or better syntactic ergonomics from dropping all the OOP baggage.
  - 3y ago
- AgentOrange1234 3y ago
  Perhaps there’s a difference between knowing and having internalized these concepts, versus having heard of them via a particular acronym, and being expected to remember that acronym and these specific names. “Liskov substitution principle” for instance is something I had to look up. I can read it and say, “oh, duh, yes that’s a key part of what interfaces are even for.” I’ve built with it for decades now. The term SOLID was apparently introduced in 2004. It would be a shame to reject good programmers who can opine intelligently on these principles, but who have not internalized this particular jargon.
  - MyFedora 3y ago
    Yes, there is quite a difference in my opinion. What does SQL stand for? No clue, but I can write you an SQL query. Same thing with HTML, CSS, PHP, etc.
    - jval43 3y ago
      That's funny. I wrote SQL daily for 10 years, read the ISO standards when working on SQL transpilers, persistence frameworks for multiple databases, etc. Even wrote a new storage engine for MySQL once. But I just had to look up what the acronym stands for! Apparently it's "structured".
  - mytailorisrich 3y ago
    Isn't that the point? Even if the candidate doesn't know the acronym you can probe if they know and understand, and be critical of, what the principles are.
  - deleted 3y ago
    [deleted]
- coldtea 3y ago
  >Certainly, asking about them and , especially, asking the candidate to critique them is a very good question ...if you're looking to hire a code quality consultant that has not written any code since the 90s
  - mytailorisrich 3y ago
    If you think those principles got out of date then indeed I would not hire you. Something like the "single responsibility principle" is just good software design to anyone who ever had to maintain any piece of software. Quite extraordinary how commenters in this thread discard things as old without even understanding that core principles are as valid now as they were then.
    - coldtea 3y ago
      >If you think those principles got out of date then indeed I would not hire you If you think your hiring criteria are some kind of general yardstick, I wouldn't want to be hired by you in the first place. What's with people using their position of power (hiring people) as some kind of argument - or perhaps threat? >Something like the "single responsibility principle" is just good software design to anyone who ever had to maintain any piece of software. The "single responsibility principle" is an ad hoc, ill defined idea. A bad idea for many real world cases, that has to be applied with discretion - not taken as a core guiding principle. Not to mention that neither "reason to change", nor "change" is well defined by Martin. It's as bad one-size-fits-all advice as advising about the ideal function being "two to four lines of code long" (also by Martin) - leading to crappy, hard to follow code, and needless abstraction. KISS - now that's a principle I would get behind.
      - mytailorisrich 3y ago
        A principle always has to be applied with discretion. Hence why I think why the OP's idea to ask candidates to critique is good. It shows whether the candidate blindly follow things as the gospel or is able to articulate limitations but also the reason behind a "principle" because there are very good reasons behind them.
ryukoposting 3y ago
SOLID is a meaningless term in my corner of the industry (firmware, where we follow the SPAGHETTI method), so I read SOLID as a placeholder for whatever the acronym-of-the-week is. With that in mind, I came to a totally different conclusion. I want to ask questions that most interviewees get wrong, because that's how you narrow down a large pool of candidates to a small pool of finalists. Augmented by a reasonable quantity of questions, pointed questions like these can serve to isolate a signal from noise.
- hitchstory 3y ago
  It's not completely meaningless but it does tend to be something people recite and then never think about - even when they're inadvertently following it. It's performative - a bit like reciting the bible. Take I as an example - "don't depend upon interfaces which you do not use". I've seen good developers cut out dependencies hundreds of times for this reason - not because they've trained themselves on SOLID but because it just feels right after years of experience. If I said "this is part of SOLID" many of them would go "... is it?" "hmmm. I guess it is..." As with reciting the bible, just because somebody recites it doesn't mean that they took it to heart and people who take it to heart can't necessarily recite it. Being able to recite it is just a ritual used as a social signaling mechanism. It's a bit like leetcode, an ability to recite big O notation or knowledge of git's internals - symbols of "developerness" that don't necessarily align with skill.
- david-gpu 3y ago
  > firmware, where we follow the SPAGHETTI method I used to write GPU device drivers. Electronic Engineers had a great understanding of the hardware, but tended to write sloppy spaghetti code. CS graduates, on the other hand, had a loose grasp of the hardware but we're better at writing solid maintainable code. Most teams ended up with a healthy mixture of the two, which worked great. I once ran into a hiring manager that only wanted to hire people like himself, with the same skills and philosophy. I tried explaining why we needed people with a more diverse set of skills and strengths, but he wouldn't bulge. Unsurprisingly his team didn't deliver much value to the company.
  - 3y ago
dasil003 3y ago
> Is the idea that you’re supposed to provide good discussion of the pros and cons, and so show some experience? That sounds like you’ll just hire people who had similar experience to you. This depends far more on the interviewers listening skills, open mindedness and maturity. Obvious everyone has their biases, but good interviewers (especially for senior positions) need to be able to evaluate how someone with different skills and perspectives will be additive to the team.
nyrikki 3y ago
DDD, Microservices, Clean, Hex, Onion, TDD, XP, EDA..... All of those follow the basic SOLID principals. The problem is the cargo culting and blog posts vs actually reading what the stuff means. S or the Single responsibility principal as an example is always explained poorly by the same people who complain about it. SRP means that "A module should be responsible to one, and only one, actor." An 'actor' being a group that requires a change in the module. making sure you decouple persistence code from domain code is an example. Almost universally the people who complain about SOLID thinks it means that you have to have trivial functions with lots of sprawl. Really it is about allowing you to make changes without stepping on another's toes or trying to coordinate with them.
- t8sr 3y ago
  Mantras like these are always a response to something. Someone in charge of technical culture at $PLACE diagnosed specific anti-patterns in their Java code, came up with a set of rules for the noobs and a catchy acronym. Things got better. Great! But then those rules got transposed into other situations, possibly by somebody else and things went downhill. Also see "Agile". Our industry, because of its huge growth, is filled with inexperienced people who learned from inexperienced people. We all know software is kind of trash, and we're coming up with ways to improve it, but the fact of the matter is we don't know what works. We know some things that don't work, and many of those were previously on a list of things that might work and had catchy acronyms of their own. A few people have enough experience to give good advice, but what they have to sell isn't a magical silver bullet with a neat acronym, and they don't use twitter, so nobody listens to them. The only thing I personally believe makes you write better code is long and varied experience with different domains, fueled by a desire to always be learning. Throw away mantras when they're no longer useful. Work like this for 10-20 years, and you'll start writing sort of OK code. Everything else ends badly.
jupp0r 3y ago
Your comment is involuntarily funny in the sense that 1999 style OOP Java is a serial offender of SOLID, not a prime example of it. It's mainly the Liskov Substitution and dependency inversion principles. If you have deep class inheritance hierarchies, you are not doing SOLID, sorry.
- t8sr 3y ago
  I’m not sure I agree encouraging inversion of control, more indirection and behavior inheritance is an improvement. In the recommended style of most languages, these are probably big anti-patterns. On the other hand, I never spent that much time working on old Java stuff, so maybe it is a step in the right direction.
  - jupp0r 3y ago
    Any time you inherit from a concrete class (vs just implement an interface) you depend on something concrete and not an abstraction.
mattchew 3y ago
I'm not crazy about SOLID principles either. They don't feel like useful, practical ideas to me. They were born to be memorized for a classroom test or a job interview. SOLID does come up in interviews, though. Most companies don't really invest in trying to do good interviews. Rarely is there anyone motivated (or permitted) to think about the process and make it a lot better or different. Doing what they've always done, or what everyone else seems to be doing, is good enough.

by t8sr 3y ago

mytailorisrich 3y ago

Hmm, SOLID is very well-known and the principles are ubiquitous good practices for object-oriented programming and also useful for software dev in general. Certainly, asking about them and , especially, asking the candidate to critique them is a very good question.

diarrhea 3y ago
Only ones I ever found worthwhile are D and maybe I.
- mytailorisrich 3y ago
  S (Single responsibility principle) is very important, not only for OOP but for good, maintainable software design in general (yes, even if you do firmware stuff).
  - diarrhea 3y ago
    Absolutely. I just find it rather inactionable, as it can be subjective.
    - mytailorisrich 3y ago
      Odd because that's arguably the easiest to apply when designing software.
- tetromino_ 3y ago
  The only part of SOLID that is unquestionably correct is "L" - it is the only sane way to use subclassing in OO languages. "D", when used judiciously, can be useful because it can make unit tests much easier to write. But when used too much, it results in incomprehensible code. But as for "I", in my humble opinion, when you find yourself reaching for it, it's a sign that the code base is already poorly organized.
  - fhars 3y ago
    But the L part is only correct in so far as it repeats the definition of what it means to be a subtype, i.e. it is vacuously true. BY the way, does any OO language apart form Ocaml get this right?
    - ahtihn 3y ago
      The L part was apparently not so obvious to the authors of the Java standard library since it has violations all over it. Readonly implementations of java.util.List come to mind.
t8sr 3y ago
It’s well known in a specific setting, possibly? I’ve managed to never hear of it in 18 years. If asking “well known to some people” stuff is kosher, should I be able to quiz candidates on FFP design principles in Haskell, or maybe how to implement collision detection in a video game? Both of those are well known in swaths of the industry. I guess if you’re hiring for a specific role, writing OOP business applications, you will have no shortage of candidates who know about SOLID, but you’re probably passing on everyone who is changing domains.
hajile 3y ago
It’s generally not what it claims. Single purpose is a good idea, but the rest… The idea that one class changing won’t change others is a pipe dream. Substitution only matters if you’re using inheritance, but if you’re inheriting, you likely have bigger problems as few real world problems are naturally represented by inheritance. The interface rule is redundant with the single principle idea. Maybe it should have been SOLD instead. Dependency injection is a guideline at best. If you actually do what it says, you get enterprise fizzbuzz. It should only be used occasionally and sparingly at specific boundaries otherwise the cure becomes worse than the disease. More controversially, when you avoid inheritance in favor of composition in a language like Java, you lose polymorphism while keep a leaky abstraction and really bad encapsulation while the language still retains all the mental and syntactic complexity of the inheritance bits. https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...
- mytailorisrich 3y ago
  > The idea that one class changing won’t change others is a pipe dream Reality is never black and white but that's a good principle for good software design and worth at least aiming for. If anything that has been adopted and generalised in microservices, etc. because encapsulation, modularity, design by contract all hinge of this same idea, which is powerful and useful. That's why when discussing any "principles" the important is to get the core idea behind them instead of sticking to the letter and discarding them as useless.
  - hajile 3y ago
    Encapsulation is extremely important and pairs with single responsibility, but that’s completely orthogonal to OOP. Once you are solidly in the composition camp, functions are immediately superior. They tend to be naturally single purpose and have mathematical rules that make them easy to compose. Most function-heavy languages also adopted modules which provide a better, less-leaky abstraction too and that’s without getting into all the other advantages in the type system or better syntactic ergonomics from dropping all the OOP baggage.
- 3y ago
AgentOrange1234 3y ago
Perhaps there’s a difference between knowing and having internalized these concepts, versus having heard of them via a particular acronym, and being expected to remember that acronym and these specific names. “Liskov substitution principle” for instance is something I had to look up. I can read it and say, “oh, duh, yes that’s a key part of what interfaces are even for.” I’ve built with it for decades now. The term SOLID was apparently introduced in 2004. It would be a shame to reject good programmers who can opine intelligently on these principles, but who have not internalized this particular jargon.
- MyFedora 3y ago
  Yes, there is quite a difference in my opinion. What does SQL stand for? No clue, but I can write you an SQL query. Same thing with HTML, CSS, PHP, etc.
  - jval43 3y ago
    That's funny. I wrote SQL daily for 10 years, read the ISO standards when working on SQL transpilers, persistence frameworks for multiple databases, etc. Even wrote a new storage engine for MySQL once. But I just had to look up what the acronym stands for! Apparently it's "structured".
- mytailorisrich 3y ago
  Isn't that the point? Even if the candidate doesn't know the acronym you can probe if they know and understand, and be critical of, what the principles are.
- deleted 3y ago
  [deleted]
coldtea 3y ago
>Certainly, asking about them and , especially, asking the candidate to critique them is a very good question ...if you're looking to hire a code quality consultant that has not written any code since the 90s
- mytailorisrich 3y ago
  If you think those principles got out of date then indeed I would not hire you. Something like the "single responsibility principle" is just good software design to anyone who ever had to maintain any piece of software. Quite extraordinary how commenters in this thread discard things as old without even understanding that core principles are as valid now as they were then.
  - coldtea 3y ago
    >If you think those principles got out of date then indeed I would not hire you If you think your hiring criteria are some kind of general yardstick, I wouldn't want to be hired by you in the first place. What's with people using their position of power (hiring people) as some kind of argument - or perhaps threat? >Something like the "single responsibility principle" is just good software design to anyone who ever had to maintain any piece of software. The "single responsibility principle" is an ad hoc, ill defined idea. A bad idea for many real world cases, that has to be applied with discretion - not taken as a core guiding principle. Not to mention that neither "reason to change", nor "change" is well defined by Martin. It's as bad one-size-fits-all advice as advising about the ideal function being "two to four lines of code long" (also by Martin) - leading to crappy, hard to follow code, and needless abstraction. KISS - now that's a principle I would get behind.
    - mytailorisrich 3y ago
      A principle always has to be applied with discretion. Hence why I think why the OP's idea to ask candidates to critique is good. It shows whether the candidate blindly follow things as the gospel or is able to articulate limitations but also the reason behind a "principle" because there are very good reasons behind them.

ryukoposting 3y ago

SOLID is a meaningless term in my corner of the industry (firmware, where we follow the SPAGHETTI method), so I read SOLID as a placeholder for whatever the acronym-of-the-week is. With that in mind, I came to a totally different conclusion. I want to ask questions that most interviewees get wrong, because that's how you narrow down a large pool of candidates to a small pool of finalists. Augmented by a reasonable quantity of questions, pointed questions like these can serve to isolate a signal from noise.

hitchstory 3y ago
It's not completely meaningless but it does tend to be something people recite and then never think about - even when they're inadvertently following it. It's performative - a bit like reciting the bible. Take I as an example - "don't depend upon interfaces which you do not use". I've seen good developers cut out dependencies hundreds of times for this reason - not because they've trained themselves on SOLID but because it just feels right after years of experience. If I said "this is part of SOLID" many of them would go "... is it?" "hmmm. I guess it is..." As with reciting the bible, just because somebody recites it doesn't mean that they took it to heart and people who take it to heart can't necessarily recite it. Being able to recite it is just a ritual used as a social signaling mechanism. It's a bit like leetcode, an ability to recite big O notation or knowledge of git's internals - symbols of "developerness" that don't necessarily align with skill.
david-gpu 3y ago
> firmware, where we follow the SPAGHETTI method I used to write GPU device drivers. Electronic Engineers had a great understanding of the hardware, but tended to write sloppy spaghetti code. CS graduates, on the other hand, had a loose grasp of the hardware but we're better at writing solid maintainable code. Most teams ended up with a healthy mixture of the two, which worked great. I once ran into a hiring manager that only wanted to hire people like himself, with the same skills and philosophy. I tried explaining why we needed people with a more diverse set of skills and strengths, but he wouldn't bulge. Unsurprisingly his team didn't deliver much value to the company.
- 3y ago

dasil003 3y ago

> Is the idea that you’re supposed to provide good discussion of the pros and cons, and so show some experience? That sounds like you’ll just hire people who had similar experience to you. This depends far more on the interviewers listening skills, open mindedness and maturity. Obvious everyone has their biases, but good interviewers (especially for senior positions) need to be able to evaluate how someone with different skills and perspectives will be additive to the team.

nyrikki 3y ago

DDD, Microservices, Clean, Hex, Onion, TDD, XP, EDA..... All of those follow the basic SOLID principals. The problem is the cargo culting and blog posts vs actually reading what the stuff means. S or the Single responsibility principal as an example is always explained poorly by the same people who complain about it. SRP means that "A module should be responsible to one, and only one, actor." An 'actor' being a group that requires a change in the module. making sure you decouple persistence code from domain code is an example. Almost universally the people who complain about SOLID thinks it means that you have to have trivial functions with lots of sprawl. Really it is about allowing you to make changes without stepping on another's toes or trying to coordinate with them.

t8sr 3y ago
Mantras like these are always a response to something. Someone in charge of technical culture at $PLACE diagnosed specific anti-patterns in their Java code, came up with a set of rules for the noobs and a catchy acronym. Things got better. Great! But then those rules got transposed into other situations, possibly by somebody else and things went downhill. Also see "Agile". Our industry, because of its huge growth, is filled with inexperienced people who learned from inexperienced people. We all know software is kind of trash, and we're coming up with ways to improve it, but the fact of the matter is we don't know what works. We know some things that don't work, and many of those were previously on a list of things that might work and had catchy acronyms of their own. A few people have enough experience to give good advice, but what they have to sell isn't a magical silver bullet with a neat acronym, and they don't use twitter, so nobody listens to them. The only thing I personally believe makes you write better code is long and varied experience with different domains, fueled by a desire to always be learning. Throw away mantras when they're no longer useful. Work like this for 10-20 years, and you'll start writing sort of OK code. Everything else ends badly.

jupp0r 3y ago

Your comment is involuntarily funny in the sense that 1999 style OOP Java is a serial offender of SOLID, not a prime example of it. It's mainly the Liskov Substitution and dependency inversion principles. If you have deep class inheritance hierarchies, you are not doing SOLID, sorry.

t8sr 3y ago
I’m not sure I agree encouraging inversion of control, more indirection and behavior inheritance is an improvement. In the recommended style of most languages, these are probably big anti-patterns. On the other hand, I never spent that much time working on old Java stuff, so maybe it is a step in the right direction.
- jupp0r 3y ago
  Any time you inherit from a concrete class (vs just implement an interface) you depend on something concrete and not an abstraction.

mattchew 3y ago

I'm not crazy about SOLID principles either. They don't feel like useful, practical ideas to me. They were born to be memorized for a classroom test or a job interview. SOLID does come up in interviews, though. Most companies don't really invest in trying to do good interviews. Rarely is there anyone motivated (or permitted) to think about the process and make it a lot better or different. Doing what they've always done, or what everyone else seems to be doing, is good enough.