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.
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.
The best firmware teams I've worked on have always had a mix of disciplines. Heck, I mentored a mechanical engineer for a while (he became a very good firmware dev). You have to have good programmers who manage to write modular, maintainable code even if the language and hardware limitations fight them the whole way. You need folks who understand Electrical Engineer-speak. Depending what you're doing, you might HDL people, and that stuff might as well be a completely separate discipline from regular software. You need people who are comfortable debugging with nothing more than log messages, and if you're lucky, a coredump. You need a manager who can wrangle the occasional "it's a hardware problem" vs "it's a firmware problem" debate.
The biggest downside of driver development is that it becomes very repetitive after a while: you are the maintainer of this immense complex piece of clockwork (the hardware) that you must to keep ticking reliably at all times by working around all the bugs in it. It sometimes feels like your beautifully crafted software contains as much code to track and work around hardware bugs as it contains code fof the idealized hardware described in the origibal documentation.
I only saw that happen at one place. It was a bit of a shitshow.
Big corps don't do that, they have a clear internal division between various levels of hardware-independent and hardware-specific components, down to workarounds for specific bugs in specific releases.
This worked for us because our approach was to "make it right the first time, update only when necessary."
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.
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.
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.
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.
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.
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.
Certainly, asking about them and , especially, asking the candidate to critique them is a very good question.
“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.
But I just had to look up what the acronym stands for! Apparently it's "structured".
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.
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/FizzBuzzEnterpris...
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.
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.
He words it poorly, but it is more about not commingling DBA, UX, core domain logic in a module.
People miss that and end up having low cohesion.
While SRP and interfaces do have an intersection, they are not the same.
Interfaces leaking implementation details is an example.
Composition, dependency inversion, and dependency injection are all forms of L.
Polymorphism is problematic in most cases but thinking it is the only way to accomplish that looser coupling goal is a misunderstanding of where we have grown with the concepts.
I tend to prefer the ports and adapters pattern, which ensures client components that invoke an operation on a server component will meet the preconditions specified as required for that operation.
That is equivalent to LSP or design by contract.
SOLID is just a set of principles that are intended to make loose coupling and high cohesion the ideal default.
This is in contrast to procedural code that we know makes unmaintainable systems.
The problem with SOLID is the same as Agile, XP etc...
People ignore the core ideas that are descriptive in nature and try to use them as oversimplified prescriptivist rules.
To be fair Robert Martin wasn't great at selling this and that is why I tend to point people to authors like Martin Fowler who are more careful about sounding like a preacher handing out laws.
But Robert Martin developed SOLID in the context of cohesion, and if you read it in that context it is valuable.
He didn't invent the SOLID tool to remember the rules, but it seems that blog posts and Wikipedia pages are as far as people get before trying to implement it or dismiss it.
We have the same problem now with software systems, although at the least we are advancing beyond the primitive stages and the charlatans are becoming more apparent.
But outside of Tu quoque fallacies, van you explain why this is a bad idea.
"A module should be responsible to one, and only one, actor."
ALWAYS look behind the curtain at what software consultants are selling to what they have actually built, and then you can ascertain if they are selling you hard won engineering knowledge or a bunch of marketing BS.
Sure he was pulling from Structural design ideas, which even Tom DeMarco, the author of the canonical book on SD, now says should have been iterative and Agile-like, but he was also pulling from papers like the following from 1972 about modularity.
https://dl.acm.org/doi/10.1145/361598.361623
The SOLID principles are a specific application of computer science principles to OO.
Separation of Concerns is a specific example of core CS principals that he pulled from but are from Dykstra.
https://www.cs.utexas.edu/users/EWD/ewd04xx/EWD447.PDF
So is your reason for discrediting him that he aspired to be a professional writer, or that he tried to collect concepts from the wider tent into a more domain specific presentation?
Because structural design is an example where the founders realized that not paying attention to that first paper was problematic.
"We have tried to demonstrate by these examples that it is almost always incorrect to begin the decomposition of a system into modules on the basis of a flowchart.
We propose instead that one begins with a list of difficult design decisions or design decisions which are likely to change. Each module is then designed to hide such a decision from the others. Since, in most cases, design decisions transcend time of execution, modules will not correspond to steps in the processing. To achieve an efficient implementation we must abandon the assumption that a module is one or more sub- routines, and instead allow subroutines and programs to be assembled collections of code from various modules."
How about addressing Robert Martin's position, instead of irrelevantly attacking random aspects of the person who is making the argument. A.K.A Ad Hominem fallacies.
In the context of this thread, if a candidate could only express their objections to _ideals_ that are intended to be the defaults, and couldn't express their objections in a way that related to business and customer needs, I would be a hard no on the hiring position.
It is OK to not agree with these ideals, but to only offer personal attacks to dismiss them, it indicates someone who will probably be a difficult team member and lack customer focus.
Ad Hominem's never address the real concerns or needs of a project and are simply not constructive.
We know that EA failed, we know SOA works better if imperfect, we know that aiming for loosely coupled and highly cohesive code results in systems that are easier to maintain and scale, and we know that with the rise of the cloud most needs will be distributed. All of those apply the same principles at a different scale or domain.
Hand waving away those well known concepts because you have a distaste for an author won't change that. But if you share ideas that address the limits of those ideas perhaps it can help move us further.
There's little to no hard science and serious research behind them, aside from Uncle Bob writing about them and some hazy papers.
The Liskov substitution principle was developed by an actual computer scientist working on such research, but the general field of programming methodology Liskov worked in remains scientifically something like what psychology was before Freud.
Not saying Freud is scientific - saying that programming methodology is even less well established and researched scientifically in 2024 that psychology was not just at the time of Freud, but even before Freud.
Dijkstra himself, in many of his notes regarding methodology, was basically 90% opinion, even when he was right.
https://arxiv.org/abs/1601.01447
There is lots of studies that show that modularity is one of the most significant factors for evaluating maintainability of OO systems.
https://www.washington.edu/is/fin/fas/standards/cobol.html
R.Martin had nothing to do with those rules related to procedural code.
No, it matters when you implement interfaces (in the Java sense) too.
Tons of real world problems are naturally solved by having multiple implementations of interfaces. Also, Dependency Inversion doesn't even make sense without it.
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.
"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.
BY the way, does any OO language apart form Ocaml get this right?
Readonly implementations of java.util.List come to mind.
...if you're looking to hire a code quality consultant that has not written any code since the 90s
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.
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.
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.