KISS principle, an acronym for “Keep it simple, stupid,” is a term created in the 1960s by Kelly Johnson while working for Lockheed Martin. which was meant to reflect the approach of creating simple, durable aircraft that could be repaired easily in an emergency. Many branches of science and engineering have since adopted this idea.
A simple solution is better than a complex one, even if the solution looks stupid.
When applied to software development, the goal is to create good code that can be easily maintained and modified by other developers.
Implementing this principle when developing software can be challenging, but it does pay off in the long run. Using the KISS principle when developing software, you should break complex problems into minor issues and solve them with a simple solution. You can also divide it logically- from monoliths to micro-services – and clean up recurring code patterns, so they’re easier to manage.
“Stupid” may be used as either an adjective or a noun. Compare the two variants “keep it simple and stupid” vs. “keep it simple, stupid!”. Regardless of all the alternative names for this idea, the general principle is still the same.
The saying “KISS” can be interpreted in many ways, including the following: Keep it short and simple, keep it simple and straightforward, or keep it smart and simple. The acronym KISS has been used for many years.
Keep it simple, stupid.
“Do not make things more complicated than they need to be.” The modern-day programming languages, frameworks & APIs are capable of creating robust solutions that can solve many problems. Sometimes it might be tempting to write clever solutions that use all these features, but sometimes, “clever” solutions can lead to clutter and make your code more complicated than it has to be. The KISS principle states that a solution is better when it uses less inheritance, less polymorphism, fewer classes, etc.
A more straightforward solution is more intuitive and easy to maintain in the long run than a complex one. This includes increased readability, understandability, and changeability of your code. Furthermore, writing simple code leads to fewer errors and saves time overall.
One of the great things about easy coding is that you can train someone new to pick up from where you left, or it is even more significant when the person who maintains the software is not the one who once wrote it. The person responsible for maintaining code might not be familiar with sophisticated and more advanced features of programming language and techniques.
From a technical perspective, simple and stupid programs are easier to maintain, and the person who carries out the maintenance is less likely to introduce further defects.
This does not mean that features like inheritance, polymorphism, and advanced framework features should never be used. They should only be used when there’s an advantage or when you need to do it. One reason developers might be inclined to create more complex code is to make it more flexible in case there are any changes in the future and to accommodate new requirements. But one cannot know how to make it flexible or if that flexibility will ever be needed.
Strategies
KISS is a very general principle, so there is a large variety of possible strategies to adhere more to this principle, mainly depending on the given design problem
- Avoid inheritance, polymorphism, dynamic binding, and other complicated OOP concepts unless required. Use delegation and simple if-constructs instead for simple solutions
- Avoid low-level algorithms optimization, especially when involving Assemblers, bit-operations, and pointers. Slower implementations will work just fine.
- Use simple brute-force solutions instead of complicated algorithms. Slower algorithms will work in the first place with a small number of input data if the solution does not demand extensive input data.
- Avoid numerous classes and methods as well as large code blocks.
- For slightly unrelated but relatively small pieces of functionality, use private methods instead of an additional class.
- Avoid adopting too many abstraction layers, a typical disease in projects that use OO languages.
Adapted from Principles wiki and used and distributed under CC Attribution 4.0 International