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.

YAGNI likes a DRY KISS

There are several acronyms which would definitely help to review code and design, improve it or confirm discussed decisions, because they actually are design paradigms and proven good practices. It’s hard to combine all of them in one easy-to-remember sentence and we wont create yet another super acronym or geek alphabets, even because the presented list is not comprehensive of all the available ones. However, many of them are worth to keep in mind and be considered when approaching refactorings and evaluating good practices. Let’s have a look at the proposed well-known acronyms:

  • SRP: Single Responsibility Principle. You can apply it to a class, a package, a component or a subsystem, no matter the granularity of your interest, there is always a domain, a business requirement to meet, and that’s the principle you should try to apply: don’t mess with responsibilities, try to identify and provide a single responsibility and you will certainly remark how easier will be to reuse the concerned class, to test it, to document it. Applying SRP, you would indirectly meet the Law of Demeter as well, lowering the coupling of your component (because you limited it to one and only one responsibility).
  • DRY: Don’t Repeat Yourself. Remember this acronym when starting duplicating code once again, when repeating the same test more than once: it will help you to achieve more reusability and automation, to collaborate with team members in order to check whether or not the same functionality or a similar one is already available and identify refactoring and improvements. And watch out: if you aren’t DRY enough then you might be WET (Write Everything Twice).
  • KISS: Keep it Simple, Stupid. I would personally avoid the last adjective, but that’s it, the acronym is well-known as it is presented and indeed you should never overcomplicate design or code, considering different approach and trade-off and finally choose the simplest one, given system constraints and business rules. If you KISS, you will definitely improve testability and your code would probably be self-documented and much easier to refactor in the future, if required. And you would automatically meet the POLA paradigm as well, Principle of least astonishment, that’s it, providing contracts, interfaces, components which behave as expected, as the user would predict. You will hence improve your usability too.
  • TDA: Tell, Don’t Ask. Think about a class which only provides get/set methods, anemic code indeed, it would not have any behavior, it would actually represent a collection of states and it could be fine for ORM entities (unless you don’t consider a DDD, Domain Driven Development approach), but it would lead to procedural code and interactions if extended to other type of classes. That’s it, the TDA helps you to maintain an object-oriented design and think in terms of behaviors, verbs, actions you would tell to execute to a given object and not just asking for values, states, properties.
  • YAGNI: You aren’t gonna need it. And if you don’t need it now, you should not waste time and energies on it. That’s the acronym to keep in mind when starting adding a not requested feature, an additional super flexible design which would probably never be required but which would definitely add effort and time to testing, debugging, documentation, justification to the customer of any matter related to the concerned component. You should try to KISS indeed.

KISS and DRY are probably easy to remember, because of their existence as real words, but try to keep all of the above in mind, somehow. A good attitude at end of each development or design phase, would be to ask ourselves whether or not the class, the package or the concerned component was meeting the SRP paradigm, whether or not we were DRY enough and the level of our KISS or if you played consciously with YAGNI. Of course, we often need to provide much more than required in order to have a flexible and extendible architecture, forecasting probable entry points and anticipating business needs, hence YAGNI is not always a good practice. TDA as well fails on most of the ORM entities implementations, but as with design patterns your experience and your project competencies should help to decide whether or not one of these design paradigms could be skipped for a certain component and scenario. And you could also play with your colleagues, inventing strange and funny comments about their DRY attitude, just don’t mess too much with KISSes though.
 

Reference: YAGNI likes a DRY KISS 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 "YAGNI likes a DRY KISS"

  1. marcin says:

    Can you share some examples? But not about Shape and Rectangle, rather something that required you to make trade-off. And discuss how following the rules lead to better code/design.
    I just see every day KISS understood differently by each developer, so articles like that does not help with anything.
    Can’t wait the followup :)

  2. antdim says:

    @marcin
    Indeed, KISS does not always lead to the same simple solution. No shape, no rectangle, think about a cache management. Real life example to share: a Struts Action received from an EJB a list of user details using pagination (you wont load the whole table, KISS), however due to wrong design the query to dig into a certain list item takes longer than expected.
    Developer1: let’s write a custom cache at Struts Action level, we shouldn’t invoke twice the EJB and load twice the same details if that takes too long (DRY?).
    Developer2: No, you don’t need yet another cache level (YAGNI) and you shouldn’t manage/fix that at Struts Action level (keep the action simple, KISS, SRP), you should either investigate why that query takes too long, improve it or improve the EJB, not the web action.

    But now guess what, the concerned query takes too long because at the beginning Developer3 said to KISS, storing some details into audit records, instead of changing a table which would have impacted backward compatibility. KISS, he said. And it was a wrong decision, definitely wrong, simulating a column/table over another table, the worst table actually, the audit record table, which in production will have millions of entries, degrading performance of any select over it. KISS was wrong in that case, because it actually generated a Technical Debt, a wrong design choice in the name of KISS.

  3. marcim says:

    Thank you for the example!

    One developer refused to extract a class (keeping functionally in private method instead) which violated SRP… two times (class had at least 3 responsibilities after that).

    Should we ban KISSing? This kind of rules must not be an excuse for bad decisions.

  4. antdim says:

    Indeed, KISS can lead to bad decision if not used consciously, I definitely agree. In the name of KISS, developers could justify everything! In general, it would be always better to double check the pairs KISS-SRP or KISS-YAGNI, but also KISS-DRY. Another example: in the name of KISS, a developer could justify duplicating a functionality, as private method, just because the functionality’s supplier was not available at that layer and it would make code a little bit more complex to use it: wrong! KISS should be also proven by component’s testability and usability.
    Thank you very much for these comments, they spotted a design paradigm which can easily lead to wrong decisions and hence to be used carefully. An abuse of wrong KISS may really lead to spaghetti code, in the worst case.

Leave a Reply


four + 4 =



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