A while ago I wrote about few design paradigms to keep in mind when designing and implementing a certain component. Among them, the famous K.I.S.S. (Keep It Simple, Stupid) kept on appearing as a valid and reasonable one. I then realized though how dangerous KISS can be when used by junior developers or, more generally, as a religion: it is pretended to be true and right, without further explanations, and hence in the name of KISS we get to justify almost everything. Often wrongly. The main concern is about what simple means in a certain context and whether that meaning breaks any other valid paradigm or, more precisely, your (technical) common sense.
We might probably apply the same reasoning to other paradigms as well, indeed correct design pattern and paradigms appliance always depends on the given contexts, but KISS seems to be a special case, because we can actually use it everywhere, anytime, in the name of simplifying things. But, are we really simplifying things?
Simple examples: in the name of KISS, a developer would prefer to have all business logic in one class (it’s simpler – you may hear – you don’t need to maintain several classes!); in the name of KISS, SQL select statement would all have the * fields selector (it’s simpler – they may say – you don’t need to list the seven required columns!); in the name of KISS… , and so on. Of course, I’m pushing it to a certain limit, but it’s clear that simpler doesn’t always mean better. As a consequence I become suspicious every time I hear someone claiming the appliance of KISS and here are a few valid points of debate, to spot a wrong KISS or at least to focus on its (mis)understanding in a certain context.
KISS may break other good practices
Is simple in conflict with other good practices? That’s probably the first and most important question. A simple solution should still be compatible with common Object Oriented practices, that is, it shouldn’t break for instance the Single Responsibility Principle (SRP) nor the Tell, Don’t Ask (TDA) practice; moreover, it should still ensure good testability (thus, simple to test as well, right?) while providing the expected behavior and functionality. Therefore when dealing with KISS try to compare (or reinforce) it against other well known practices and guidelines, defy it, don’t assume it right by the mere wonder of simplicity.
KISS may break performance
Does simple mean slow? Simplicity doesn’t always match with well performing and that could certainly be a red flag when KISS is in the air. Think about simple SQL queries which then perform poorly or simple algorithm implementations which then unnecessarily need an huge amount of memory or deployments which would not scale gracefully on the number of requests or users. We often cannot keep it simple and we would not be stupid indeed.
KISS may be quick and dirty
Does simple mean authorization to workarounds? You may still be conform to OO practices and provide reasonable performances, but in the name of KISS you could also add methods or parameters just because it would easily and quickly (and in a simple way) solve a certain issue. Right, nothing wrong with that as long as we are not introducing side effects or unexpected coupling, as long as we are not breaking contracts consistency or introducing unwanted future compatibility to keep, as long as we are also conform with the Principle of least astonishment (PLA), that is, not degrading user experience. Watch out hence as soon as simple means shortcut.
KISS may justify whatever solution
Does simple really make sense? As an overall rule, you may even doubt about how simplicity is intended to be applied in a given way and context and why should a certain simplicity be preferred over another. Yes, simplicity may have several faces and meanings, depending on final goal (what you really want to achieve, simple means you immediately see the solution), time (simple means you don’t have time for other solutions), constraints (simple means you don’t have other solutions), skills (simple means you don’t know other solutions). Moreover, when KISS is the only justification or advantage, try to seek at least a second one, don’t blindly trust purely KISS solutions.
As usual, our common sense and experience should guide use to the best choice, design patterns and paradigms are not silver bullets and should always be used consciously. Sure, simplicity is a great goal to achieve and an attribute worth to provide in terms of maintainability, readability, cleanness and yet elegance, but it should thus never mean less quality. You should hence mistrust KISS when it does smell like one of the scenarios above, because indeed its ambiguity may lead to the complete opposite outcome: complexity and troubles. It happens in real life as well, you might look for a KISS but you finally get a SLAP (Simplicity Leaving Awkward Problems).
Generally, when it comes to performance, you should still apply KISS initially. You should only adjust for performance if you NEED to. Also, in getting the simpler solution working, you may find out things needed to make it work that would have been harder to spot in the more complex solutions.
@ But again, as the article tried to spot, simplicity may be misunderstood, example: the simplest SQL query (here: the solution) would use a star field selector while a (less simple? simpler? points of view.. ) query would select only the two required columns (more readable, better performances, less simple? simpler?). I agree, always try to implement a simple solution first and then improve it step by step, but the starting point, the starting applied “simplicity” must be a reasonable one. I have seen many over-engineered solutions in the name of KISS which of course didn’t absolutely match with what… Read more »
Not only as a coding practice, but KISS should also be applied consiously while designing user interfaces. I agree with you that KISS should not be applied everywhere as a rule of thumb.
I prefer the “Keep It Stupid Simple” version as it states it should be simple and easy to understand.
Then good practice is a must have because often leads to better understanding of the produced solution.
Also KISS is not a solution, it’s a philosophy to be applied by architects and senior developers.
KISS is clarity.
KISS is easy.
KISS is maintainable.
KISS is good practice.
KISS is use of the good tool.
KISS is focusing on the current problem, keeping in mind the upcoming problems but not making a YAGNI solution when you solve the future “perhaps occuring” problems.