Should I Care about SOLID?

Before we examine the many reasons why we should care about SOLID, let’s address the reasons people give for not using it: 

“I implement OOP.”

People who use OOP often say they do not want to use SOLID. However, while OOP provides a paradigm to write programming, paradigms are not principles that instruct you about the kind of responsibilities a class should have. Writing OOP doesn’t guarantee that you follow design principles.

So yes, you should care about SOLID even if you’re writing object-oriented programming.

“I can implement design patterns.”

What are design patterns meant for? These patterns only tell us how to design programs and software. But SOLID principles guide us in making our code better and cleaner.

For example, consider a scenario of observer pattern. It tells us about the pub or sub model, how the receiver or sender gets notified, and how we can design our classes in order to fulfill observer patterns. But it never guides us on making our code cleaner and better placed.

“I use Java, not .NET/C#.”

SOLID principles are not related to any programming language, which means they are not built for any specific programming languages—the language in which the program has been written doesn’t matter. SOLID principles are simply guidelines for making our code and programming robust, even if we are working in JAVA.

“I am an architect.”

If someone says these principles are not for architects, they are not being realistic. Architects think about robust design, scalability, and components distribution, and while designing any software or application, they should also be keeping in mind SOLID principles. Yes, there are chances for overlap, but in order to make application design robust, these people in particular should follow SOLID principles:

• A developer who needs to write code.
• A reviewer who reviews code/area.
• A tech lead who guides a team.

“I am working on a maintenance project.”

You should care about SOLID principles even if you are working on a maintenance project. Let me share a relevant experience from my professional life.

A long time ago, I worked on a maintenance project. By the time I joined that team, the project was almost done. I got an assignment and noticed a much-repeated code snippet throughout the application, but the assignment, including QA efforts, was due in two days. 

I approached my team manager about the situation, but he said, “We are almost done with this project. I don’t care about the SOLID principles. Besides, we have a green flag from our clients. If you can't complete this task on time, I’ll have to assign it to someone else. The choice is yours.”

That really wasn’t my day.

What did I do? Well, I am a developer, and we developers don't want to leave tasks incomplete. So I completed the assignment before it was due, but I did so in my own style. I wrapped up a new class and added new functionality related to my task, wrote it using SOLID, and attached the similar things with this class so that other areas of code could feel SOLID. When I sent my changes for review, I sent them with these notes:

“I noticed a lot of code is repeating itself. Code at some places is really unmanaged and needs to be cleaned up. I implemented my changes by obeying SOLID principles.”

My changes were approved after QA and deployed with release, but afterward we got a call for code review by the client. A few senior people from our team attended the video conference call. Suddenly, I got a call at my desk from my manager, who said, "Come to the conference hall—the client is calling.”

I was shocked when the client asked about my work experience and why I had written the code in this way. Man! I wasn’t sure what to think.

Then the client clapped and said, “Great. You've done it the right way.”

What if I had thought, “I am a developer working on a maintenance project, and my project is undergoing final release. Why should I bother about all these principles?”

“I do QA and work with Selenium.”

I recently attended a seminar at an engineering college (for its science festival), and one QA developer said to me, “I am a quality-assurance person, and I work with Selenium. Why should I care about SOLID?”

My answer is simple. In some companies, the QA developer must write all the code in order to automate his or her QA process. In this scenario, SOLID principles are especially important.

“I am a technical consultant.”

If you’re a technical consultant, it’s your duty not only to provide technical consultancy, but also to guide your client to write good code, which means you must adhere to SOLID.

That dispenses with the mythology about not needing to care about SOLID while writing code, programs, or software.

Table 2: Should I Care about SOLID?

Keep in mind that this list isn’t comprehensive. Depending upon the situation, others involved in coding might also need to follow SOLID principles.