KISS vs SOLID

There is an eternal "holy war" between developers who want the application to be as simple as possible and the ones who want to introduce as much flexibility as possible. The first group votes for the KISS principle, while the second group considers SOLID as a cornerstone. Let us see what all this fuzz is about.

Simplicity

Let us start from the KISS that represents a simplistic approach. This principle's main idea is to simplify everything as much as possible. Then we need to understand what is going on and how to deal with it.

The advantages of the KISS principle are also clear and easy to see. If all internal processes and components are straightforward, they take less time to figure out how they work and modify them. It is also significantly easier to plan further actions and estimate how much time you will need. Consequently, these estimates' accuracy is usually high, so the company needs fewer resources to compensate for overtime. All these benefits lead to a quick, transparent, and relatively cheap development process.

However, some projects with an average or above-average size may require some complex components, which are extremely hard to build using the simplistic approach described above. It may become crucial if the application requires a certain degree of flexibility, which almost always increases overall complexity. Such scenarios are usually implemented using SOLID principles.

Flexibility

The flexible approach based on SOLID principles can also be simple and easy to understand. However, it is more commonly used to build multi-purpose or reusable components, which assume a certain level of complexity.

SOLID's main advantage is stable and extendable architecture, so future modifications will not break the existing structure and will not raise complexity. Solution flexibility is a consequence of good architecture. Such flexible solutions are also cheaper for support from a long-term perspective, especially on big projects.

The disadvantages of the flexible approach are extra time and cost needed to use it properly. Good architecture, thorough planning, proper development processes take time and money. That is why transparency and excellent communication are crucial for a flexible approach to achieve good results.

But can we combine the advantages of both simplistic and flexible approaches and avoid the disadvantages of both at the same time?

KISS + SOLID = ?

We can indeed combine some of the advantages of both approaches but only to a certain point. This point is usually the requirement that requires a certain level of complexity to implement the requirement. Disadvantages work the same way — you may eliminate or compensate them only partially. So, what can we do about it?

Every time you have to select between the simplistic and flexible approaches, you must first consider the simplistic approach. If the requirement is easy enough, you should start from the faster and easier implementation, keeping in mind that it may be changed in the future.

Another good recommendation is to keep in mind all limitations — time, finances, and experience. This way, you can always know when you need to switch to a different approach or change the application architecture.

To get the best of both worlds, you should keep in mind all the traits of these approaches, combine them if possible, and choose the correct approach to maximize effectiveness with minimum resources.