Understanding the KISS principle Aug 23, 2015

KISS stands for “Keep It Simple Stupid” -no comma, no offense :-) it is a kind of design rule which states simplicity over complexity to avoid creating systems difficult to understand and maintain. I am a big fan of this principle, but from time to time I have discussions with people about how to apply it in software systems. It seems to me, as always, is a terminology issue between: simple, complex, complicated and difficult. And, as it involves people, it always gets controversial and complicated.

Everybody, more or less, knows the meaning of simple -something easy to understand-, but, what is the meaning of complicated? and, what about complex?. The difference is how one can understand, replicate or predict the behaviour of such as system. A complicated system can be divided into small parts, by understanding each part and the interactions with others, one can understand the complete system. Difficult has nothing to do with those terms, it is a qualitative attribute which depends on the knowledge of each person. But, in general, we can admit that something complex implies some kind of difficulty, but something complicated not implies something (directly) difficult per se, it only implies that it has other pieces and it needs to pay more attention.

As engineers, we are always developing processes and algorithms to transform data into information, and I like getting some inspiration from the nature, lets do it. Along time, iteration after iteration (evolution), it has faced similar problems that we have in our systems and most of the times, we only need to have a look about how they were solved.

Light dependent reaction
Light-dependent reaction of photosynthesis (from Wikipedia)

Let us take a difficult to understand process of nature as the photosynthesis. It is the process that most of the plants use go get energy from the light and transform it. At a first glance, photosynthesis is a really complex process: it involves chemical reactions between molecules, electrons, photons … so, to fully understand the workflow, you have to know, not only biology, but also quantum physics. Actually we know, it is one of the most efficient processes to get energy from the light, but, is it complex in reality? I do not think so: it is efficient, repeatable and stable, resilient and scientifics have defined the process. For a person with no knowledge about those subjects -like myself-, it is complex, thus really difficult to understand. On the other hand, paradoxically, climate is a complex process, I can make some short-term predictions (hours). There are models to try to make mid-term predictions, but nobody has an algorithm to do it, because it has a lot of unknown variables (it is a chaotic system). It is more than difficult to analyze and replicate, thus no deterministic.

Complicated systems should be predictable in the same way that a watch is deterministic. An algorithm cannot be complex, only complicated (ofc some of them produce complex results … but on purpose … see genetic algorithms. In my opinion, that is the main quality to design resilient systems. It is a balance, one has to understand the requirements, analize the problem and define a solution, iteration by iteration to improve other qualities like performance, security, etc. Unfortunately in reality most of the times is not possible creating simple systems, and reaching the point of complicated systems is when a good engineer makes the difference with qualities that are difficult to explain: experience, flexibility, elegance … avoiding other risks like over-engineering and keeping simple for the end users.

And then, YAGNI “You aren’t gonna need it” comes up … but I think it deserves another post about that. I would say that a YAGNI focused approach can clash with ideas like patterns, design … specially if it is not reasonable. The concept was created for eXtreme Programming methodologies to stop developers doing things that customers will not need, so, the first question should be: is this idea applicable to your case?. A good rule is: be rationale, set priorities, short-term and long-term requirements and reach agreements with developers. Remember what Einstein said: “Everything should be made as simple as possible, but not simpler”.

Anyway, chaos is beautiful and I will leave for other day the meaning of elegance … :-)

Related Posts