DRY, KISS & YAGNI Principles

DRY Principle

DRY stands for Don’t Repeat Yourself.

Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.

This means that you should not have duplicated code. It’s easier to maintain a code that is only in one place because if you need to change something in the code, you just need to change in one place. Besides that, if you have the same code in two or more places, the chance of this code become different during the time is high, and when this happens it will become an easy way to introduce bugs in your system. Duplicated code also makes the code more complex and unnecessarily larger.

You also should not write ambiguous code. Your classes, your variables, your functions, they should have a specific name, and their name must match their responsibility. If you have a function, you should know what the function does by just reading its name, without being needed to read the code inside of it.

DRY is also about having different code that does the same thing. Maybe you can have different code in two or more places, but they do the same thing in different ways, this also should be avoided.

But DRY principle is not a dogma. Sometimes is better to consider AHA principle.

AHA (Avoid Hasty Abstractions)

AHA - prefer duplication over the wrong abstraction

The key is that we don't know what the future of code will be. We could spend weeks optimizing code for performance, or coming up with the best API for our new abstraction, only to find out the next day that we made incorrect assumptions and the API needs a complete rework or the feature the code was written for is no longer needed. We don't know for sure. All we can really be sure of is that things will probably change, and if they never do then we won't touch the code anyway so who cares what it looks like? We should be mindful of the fact that we don't really know what requirements will be placed upon our code in the future.

The big takeaway about "AHA Programming" is that you shouldn't be dogmatic about when you start writing abstractions but instead write the abstraction when it feels right and don't be afraid to duplicate code until you get there.

KISS Principle

KISS is an acronym for Keep It Simple, Stupid. This principle says about to make your code simple. You should avoid unnecessary complexity. A simple code it’s easier to maintain and easier to understand.

You can apply this principle in the design and in the implementation of the code. You should eliminate duplicated code, should remove unnecessary features, don’t use unnecessary variables and methods, use names for variables and methods that makes sense and matches their responsibilities, and always when it’s possible, follow know standards of code development. You also should separate the responsibilities of your classes and the responsibilities from the layers of the project.

Sometimes you don’t need to implement something new to attend your needs, you can simply make use of the features of the programming language that you are using. For that, it’s good that you know the features of the programming language that you are working with.

If you are working in a code that it’s already implemented, and you see something that it’s not necessary or could be simpler, you should consider refactoring it.

YAGNI Principle

YAGNI stands for You Ain’t Gonna Need It. It’s a principle from software development methodology of Extreme Programming (XP). This principle says that you should not create features that it’s not really necessary.

This principle it’s similar to the KISS principle, once that both of them aim for a simpler solution. The difference between them it’s that YAGNI focus on removing unnecessary functionality and logic, and KISS focus on the complexity.

Ron Jeffries, one of the co-founders of the XP, once said:

Always implement things when you actually need them, never when you just foresee that you need them.

It means that you should not implement functionality just because you think that you may need it someday, but implement it just when you really need it. Doing that you will avoid spending time with implementations that were not even necessary, and maybe will never be used.