Impact of SOLID principles in projects

The impact of SOLID principles on projects

In the previous article, we discussed one practical way of applying SOLID principles in projects.

Today, we would like to discuss the SOLID principles' benefits. About their pros and cons and about, the change they bring to projects => about their impact.

In general, we can observe 3 areas of impact:

system stability
faster delivery & onboarding
overhead

System Stability

One of the main benefits of using the SOLID principles is that they help to ensure that global changes do not require changes to all applications. This improves system stability, as the system is harder to break.

We could say the system now has more “legs” — modules, classes, and interfaces created to be SOLID-compliant.

For instance, imagine a situation when we’ve just implemented a Façade pattern to ensure our classes have only Single Responsibility.

Now, when we break something in one class that implements the Façade interface, the others stand still.

Additionally, a stable system is more likely to fail during build than in runtime. For example, when we change a method signature in our Façade interface, we immediately notice we must adjust the implementations of that method. On the contrary, if we don’t separate the responsibilities using a Façade, adding another switch case to the existing method could influence its consumers in an unwanted, error-prone way.

It provides stakeholders with greater confidence in the system when it fails less in the runtime.

Faster Delivery & Onboarding

The SOLID principles also help to increase the speed of delivery due to improved code readability.

It’s like a carpenter using well-crafted tools to build a house. The carpenter can work faster and more efficiently if the tools are sharp and well-maintained and when he knows them well. Similarly, when software developer applies the SOLID principles to their code, it makes the code more organized and understandable — allowing the developers to work faster and more efficiently.

In other words, SOLID principles reduce the risk of the infamous spaghetti code occurrence, which leads to the reduced amount of (onboarding) time it takes for new developers to become accustomed to the codebase and to gain such a level so they break stuff less often.

Better code readability is also beneficial as it means that a high level of expertise from the developers is no longer critical (e.g. before seniors only, now also mid-level).

The result can be faster development since writing properly the classes, modules, and interfaces to make the code more readable gives developers more detailed knowledge about the system.

Additionally, the development experience is improved, as there is less boilerplate code to write in the “client” side of the code — the code that uses our SOLID-compliant system implements its interfaces, etc. It makes life easier for the other developers — consumers of our code.

Overhead

It should be noted that overhead is associated with applying the SOLID principles. This can include the cost of creating the interfaces, classes, and modules and the cost associated with evangelizing and educating developers on the principles.

However, in the long run, these costs can be offset by the time and resources saved due to the previously mentioned improved system stability and code readability.

Who and when will notice the change?

To measure the impact of SOLID principles, we could focus on key roles and how they perceive the changes in the project after the intentional application of SOLID. The key roles are: the (other) developers, tech-lead(s) (or senior developers, if you will), testers, and managers, and they could notice the change at these moments:

Developers will notice the change at code review when they realize that the code is now not as straightforward as it used to be due to the additional “layers” (classes, interfaces, modules).
Tech-lead(s) will notice the change when the new developers need a shorter time to produce changes without breaking the system.
Testers will notice the change when the previously very buggy part of the system is now less buggy.
Managers will notice the change when the feature that was expensive to change is now less expensive.
Managers will notice the impact when developers present at the retro that they are happy with the benefits regarding the development experience that the SOLID principles have brought in the last sprints.
Managers will notice when some system that was regularly a central topic in the management meetings before releases suddenly is not. Nobody is scared anymore that it will fail and that customers will complain.

Summary — the impact of SOLID

Global changes do not mean the necessity to change all applications
The system is harder to break (it has more “legs”: the modules, classes, and interfaces)
The system fails instead a during build than in runtime
Less worried stakeholders
The high expertise of the developers is no longer critical (before seniors, now also mid-level)
Better development experience, less boilerplate in the client’s code
Faster development because writing interfaces, classes, and modules in the correct SOLID-compliant way gives developers more detailed knowledge about the system
Shorter onboarding time
Shorter time until the new developers are mature enough, so they break something less often.
Creation of the interfaces and modules has its cost but saves resources in the future.
Evangelization and education about SOLID have its cost. It is an investment in human resources through

Bonus — what should a software crafter do to write SOLID-compliant code?

To conclude our two SOLID articles, these are our recommendations for anybody keen to write stable, maintainable code that works and brings results to the clients or to the world:

A SOLID-compliant software crafter should be able to understand the theory behind the SOLID principles and be able to use them to solve real project problems or to improve something.

They should be able to connect the solutions with the theory of SOLID principles, as well as have the argumentation (rhetoric) to explain the benefits to the stakeholders.

Additionally, they should follow the SOLID principles when writing their “daily” code and keep the system in compliance with them, as well as educate their teammates, suggest improvements, and be able to deliver them.

Finally, they should repeat this cycle to achieve a long-lasting stable impact on the project.

My thanks go to my exceptional colleagues @Pawel Kruszewski , Mato Ďuriš & Matej Kolečáni, who helped me to craft this blog :)

Impact of SOLID principles in projects was originally published in ableneo Technology on Medium, where people are continuing the conversation by highlighting and responding to this story.