Ref: http://www.javacodegeeks.com/2014/03/use-kiss-consciously.html
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 simplemeans 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).
