About Antonio Di Matteo

Antonio is a passionate software engineer who continuously seek improvements and challenges. He is also a restless dreamer and at the moment he is potentially involved in such activity.

Use KISS consciously

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).
 

Reference: Use KISS consciously from our JCG partner Antonio Di Matteo at the Refactoring Ideas blog.

Do you want to know how to develop your skillset to become a Java Rockstar?

Subscribe to our newsletter to start Rocking right now!

To get you started we give you two of our best selling eBooks for FREE!

JPA Mini Book

Learn how to leverage the power of JPA in order to create robust and flexible Java applications. With this Mini Book, you will get introduced to JPA and smoothly transition to more advanced concepts.

JVM Troubleshooting Guide

The Java virtual machine is really the foundation of any Java EE platform. Learn how to master it with this advanced guide!

Given email address is already subscribed, thank you!
Oops. Something went wrong. Please try again later.
Please provide a valid email address.
Thank you, your sign-up request was successful! Please check your e-mail inbox.
Please complete the CAPTCHA.
Please fill in the required fields.

4 Responses to "Use KISS consciously"

  1. Jake Zimmerman says:

    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.

  2. @Jake
    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 simplicity should have looked like in that context. That is, I accept your KISS if it doesn’t break other good practices and common sense (hence, trying to “standardize simplicity”, somehow). About performances, indeed it may be a less important constraint on the appliance of KISS, depending on the context though.

  3. Abhijit says:

    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.

  4. Nate Roberts says:

    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.

Leave a Reply


8 − = two



Java Code Geeks and all content copyright © 2010-2014, Exelixis Media Ltd | Terms of Use | Privacy Policy | Contact
All trademarks and registered trademarks appearing on Java Code Geeks are the property of their respective owners.
Java is a trademark or registered trademark of Oracle Corporation in the United States and other countries.
Java Code Geeks is not connected to Oracle Corporation and is not sponsored by Oracle Corporation.
Do you want to know how to develop your skillset and become a ...
Java Rockstar?

Subscribe to our newsletter to start Rocking right now!

To get you started we give you two of our best selling eBooks for FREE!

Get ready to Rock!
You can download the complementary eBooks using the links below:
Close