A Detailed Explanation of The KISS Principle in Software

A Detailed Explanation of The KISS Principle in Software

When you search about the KISS principle on The Internet, you stumble across a lot of websites which will define it in a couple of lines. Therefore, you could think that this principle is easy to understand, easy to apply, or even not really important.

[…]

Now, what’s the difference with easy? Well, let’s look at its definition:

[…]

Let say you have to do a binary addition and you have no idea how to do it: it’s not easy for you. You lack some knowledge. However, a binary addition is not a system with too many parts. It’s not a system with connected parts. Therefore, it’s definitely simple.

[…]

Fools ignore complexity. Pragmatists suffer it. Some can avoid it. Geniuses remove it.

[…]

If you stumble across some code or functionalities created for no actual present purposes, delete it. If it will be indeed implemented one day, you can still come back to it with your version control system (git, anyone?).

[…]

All these conditionals can be seen as many little parts of a method, for example. Remember: many parts is the first Sin of Complexity™.

[…]

Another problem with conditionals can be the conditions themselves. There can be way too many nested parts in there, like this kind of thing:

[…]

I will never say it enough: pain will wait for those who take this forbidden path, for them and everybody who works on the cursed application.

[…]

This is a very good example to show that complexity can indeed be summarized by a system with too many parts.

[…]

What’s an abstraction? It’s a way to deal with complexity by offering a layer of simplicity on top of it. I wrote about it in depth in another article.

For example, a function is an abstraction: when you call a function in your code, you won’t necessarily know the implementation of that function. You won’t be aware of its complexity: how many parts it has, how much it depends on other parts. You will just looks at the name of the function and use it, or try to find something better for your needs.

[…]

In general, ask yourself: does your application need this flexibility? Do you really think you will need to swap this or that with something else?

[…]

It’s safe to say that too many dependencies in a system make it horribly complex. After all, by their nature, dependencies couple parts of your system with one another: the definition itself of the Unforgiven Second Sin of the Complexity of the Death.

[…]

To come back to my lasagna architecture with 11 layers, this design was created up front, with the only purpose of hyper flexibility. It wasn’t a rewriting or a refactoring: it was created as it is now.

[…]

Everyone knows that debugging is twice as hard as writing a program in the first place. So if you’re as clever as you can be when you write it, how will you ever debug it?”

[…]