I’ve been a programmer for just under three years. At least every other month since starting my illustrious career, I’ve reconsidered, reinterpreted, revised or otherwise changed my understanding of SOLID principles. I get the impression that this isn’t entirely my fault.

Scouring the internet, you might find a blog explaining the Dependency Inversion Principle. Further browsing will take you to some Reddit thread that contradicts what you’ve just read. Your coworkers probably disagree with whatever material you’ve come across online, and with each other. I’ve seen internal coding standards documentation which defined Dependency Inversion to mean “depend on abstractions, not concrete implementations,” and then conveniently link to the Wikipedia article which defines DIP altogether differently. The same documentation mandates that “All code should follow SOLID practices.” Everybody has a different interpretation, and everybody thinks theirs is the right one.

These observations are neatly compiled for the cynicisian’s reading pleasure in the pertinent and perfectly simple StackOverflow question: What is the dependency inversion principle and why is it important? Evidently, it’s a harder question to answer than ask. The top reply is by a highly-repped (read: knowledgeable) user talking about the need to use Java-style interfaces to satisfy the Dependency Inversion Principle. You can see an even more highly-repped user disagreeing altogether with that explanation in the comments. Others are conflating Dependency Inversion with Inversion of Control. Another has a crazy hexagon diagram stuck in there. One seems to agree with my current interpretation, but ask me again in six months.

Meanwhile, I’ve spent the last three years trying to actually apply these principles like an asshole.

In the real world, a lot of this stuff seems to go out of the window pretty quickly. There are some bad habits that persist, like sticking interfaces on every class because it’s “inverting the dependency so it’s SOLID,” or “to make it testable.” But otherwise, developers seem to be aware, consciously or not, that applying SOLID dogmatically wherever and whenever you can is a bad idea. Developers don’t invert the dependency on the .NET Framework. We don’t religiously segregate every interface from every client. We would never create entire plugin systems where simple switch or if statements suffice (though I have been told that that’s a good idea by some people).

There can be some crazy stuff that comes out of the people responsible for designing coding standards and best practices when they canonise SOLID. I’ve worked with standards that rather than calibrating to the needs of each system, instead broadly require insane design patterns be used for the simplest of projects in the name of so-called maintainability. I’ve seen perfectly serviceable repositories thrown out in favour of batshit CQS implementations simply because the author of those standards considered them more SOLID. The principles slow things down, cause confusion, make people less productive and, ironically, can make the codebase harder to maintain when applied too broadly.

My best guess is that SOLID is a vogue conversation piece. A technique thought essential for every programmer to master, lest they are unable to write maintainable software. A fun topic to argue about, and more fun to show off about. A good way for us to swing our dicks about and compare who’s more, er, SOLID.

During the interview at my current place of employment, the interviewers asked me to explain SOLID principles. I rattled off some gibberish definitions, I think lifted from Wikipedia and then mangled by memory and pressure. It was something I would definitely not recognise as SOLID; I didn’t really recognise it at the time. I still got the job. And I don’t think I was—or am—a horrible developer for my lack of clarity and changeability on the matter. Given its universality as an acronym and conversation material, it might be adequate for interviewers to confirm that candidates are merely aware of the principles, and bother to spend time reading about them online. Flawed understanding or not, it demonstrates some initiative and ability to self-learn. Even if it is just recycled Reddit crap.

My own experience with SOLID is mixed. I’ve overcomplicated things before, applied interfaces to everything (which stemmed from a bad interpretation of DIP) and worried about things I didn’t need to because I thought my code absolutely had to be SOLID through-and-through. I can only speak to my own reasons for falling into these traps, but I suspect many will empathise; for me, it was a case of insecurity and lack of certainty that what I was writing was maintainable or correct. All the talk of SOLID, which other people seem so confident and assured about, makes you overcompensate for gaps in your own knowledge. That isn’t helped by much of the Google material on the subject being contradictory or nonsensical.

Having said all this, I’m a fan of SOLID. But it’s useful to remember that the word fan comes from the term fanatic. To me, SOLID is a collection of sensible ideas that often apply, in principle, to languages and systems that aren’t just C++, Java or C#. A fact which some people don’t notice. In hindsight, I wish I’d had the understanding I currently have. Some of the mistakes I’ve made when creating software could have been mitigated by sensible application of the principles as I see them now, though it goes without saying some of those problems wouldn’t have existed were it easier to avoid some of the sillier interpretations of SOLID. I suppose the adage you have to fail before you fly holds up!

Developers tend to have a certain level of pride in their knowledge and expertise. It’s good to be passionate about one’s craft and respect the time you’ve invested in yourself to learn it. However, when confronted with hack-bullshit it’s easy to think less, professionally, of the person spouting it. I’ve been there with regards to SOLID, and I’m sure others experience similar thoughts about my opinions. But you might be surprised to find out just how many people have a different understanding of the principles to yours. To the extent that it’s almost completely useless to gauge someone’s ability based on their knowledge of SOLID.

Most recently, I’ve learned to have more confidence in myself and my work. That’s not to say I’m not sceptical or critical of what I write, I absolutely try to be, but only that I now feel less like I need to program on rails. SOLID principles make for great guidelines, but it doesn’t seem useful to let them become more than that. When you find yourself zealously combing through code trying to “make it as SOLID as possible”, it could be time to temper your fervour and reach a compromise with imperfection, which usually turns out to be simplicity.

For others having difficulty grasping the amusingly gaseous ideas of SOLID as explained by much of the internet, I would highly recommend checking out the original Uncle Bob papers that introduced the acronym here.