Strive for simplicity

KISS, DRY (Don´t repeat yourself) and YAGNI (You ain´t gonna need it) are some of the most famous principles in programming, but KISS it is often misunderstood.
Too often the acronym is explained as

Keep it simple, stupid.

instead of

Keep it simple stupid. ( no comma )

Even if the underlying concept is the same I always found the first interpretation kind of rude because without the comma was is stupid is the simple thing, (it is so simple that it is stupid), while with the comma the one being stupid is the developer. And that is not something you want to say to someone you are mentoring or pair programming with.

Nevertheless, the idea is simple. Do not over complicate things!

But why are we complicating things - in life and in code?

We naturally overcomplicate things we don’t understand

Has it ever happened to you that you implemented something a feature in hacky - complicated ways just because we did not really understand how the framework or library worked?

When we are looking at something big and complex, or when we have little knowledge of how something functions, it is normal to overcomplicate it, or at least to consider it super difficult ( unless you suffer from Dunning Krueger, then you will think it is eaaasyyy!)

What is the complexity bias?

Complexity bias is a logical fallacy that leads to the belief that complex solutions are better than simple ones. It refers to an irrational preference for complexity over simplicity.

Faced with two competing hypotheses, we are likely to choose the most complex one. We tend to think that the simple solution, is too simple for the complexity of the problem and therefore "it will never work”.

When we explain our architecture we need to use big words and jargon to get more credibility, when we write our implementation, let´s just stuff in a couple of Design Patterns - to look cool and be future proof ( even though, most of the time... YAGNI)

For every complex problem there is an answer that is clear, simple, and wrong.

I loved this quote, and I used that so many times in the past - especially when a project manager not happy with my estimates, tried to squeeze the story points of my task saying:

cmon, it can´t be so hard to implement that, there must be a simple solution!

But over the years, I noticed that in fact, most of the time there is a simpler solution available.
Actually I became very suspicious when during standup I hear colleagues say for example they want to rewrite from scratch some functionality or component from 3rd party libraries because they are too complicated. Most of the time with a few minutes of pair programming, and of careful read of the documentation - or further googling, the solution was there simple and at hand.

We should strive for simplicity in software( - and in life)

So what do we do?

• Don't confuse Simple with Easy, and Complex with Hard. Something can seem hard ( or complicated ) just because we are not used to it.

hard becomes easy through familiarity, but complex rarely becomes simple

• When something is in fact complex. Split it into smaller simpler tasks.

Software development is the act of breaking a complex problem down into smaller problems and composing simple solutions to form a complete solution to the complex problem.

Some time ago I found this amazing talk about the complecting (or interleaving) of things:

and I´d like to quote a couple of things

Simplicity is a Choice
- Requires vigilance, sensibility, and care
- Equating simplicity with ease and familiarity is wrong

Simplicity Matters
- Complexity inhibits understanding, and therefore robustness
- Simplicity enables change and it’s the primary source of true agility.

So I don´t need Design Patterns and complex code?

Don´t get me wrong.
I am not saying that everything IS simple, that every task is easy, or that Design Patterns are useless.
What i mean with Strive for Simplicity is that we should really make our best to make everything simple, that every implementation SHOULD be simple (or at least should be simple to read and understand after you wrote it - think about how

• conventional commits and automatic changelogs,
• atomic commits,
• Test Driven Development,
• separation of concerns,
• SOLID principles
• proper logging
• ...

help to maintain the code base clean, to reduce technical debt and keep debugging sane) and that mastering the skill of knowing what to add or what to remove to your design requires a lot of study, practice and experience.

To complicate is easy. To simplify is difficult.
Everyone is able to complicate. Few are able to simplify. (Munari)

So Keep it Simple Stupid, Don´t be Stupid! ;-) and do not go further than that!

Photo by Olia Gozha on Unsplash