What is the KISS rule in programming?

Term KISS is present in tech jargon all over: in articles, books, in your office discussions. KISS simply means: Keep it Simple, Stupid. Sounds easy enough, but what it really means for software development, and day to day tasks?

Art of Unix Programming
UK: https://amzn.to/2GB0eNl US: https://amzn.to/2U2uaVN
#programming #tech #softwaredevelopment

Software engineering very generously sources knowledge from other kinds of engineering. In this case - KISS was drawn from aircraft engineering. This rule, invented by Kelly Johnson states that all systems work better if they’re kept simple rather than made complex. There are other rules like it: “Occams’s razor”, “less is more”, or even “make simple tasks simple”.
This is the very nature of what we do as software engineers - we take complex concepts, like sending a rocket in space, and we break it down, simplify, come up with powerful abstractions, and simplify them even more. Up until we can come up with a design that can be formed as a diagram, list of steps, an algorithm or a final source code to compile.
So how do we execute this rule in software? Observe how unix executes this philosophy, and try to follow: Make each program do one thing well. To do a new job, build afresh rather than complicate old programs by adding new "features". Get it? Don’t invent complex systems to do simple tasks.
Articulating what exactly KISS means isn’t easy, but we can approximate the answer by referring to design rules from Eric’s Raymond Art of Unix Programming. There’s quite a few of them, so if you’re interested I suggest getting that book, link in the description. Here we go:
Build modular programs
Write readable programs
Use composition
Separate mechanisms from policy
Write simple programs
Write small programs
Write transparent programs
Write robust programs
Make data complicated when required, not the program
Build on potential users' expected knowledge
Avoid unnecessary output
Write programs which fail in a way that is easy to diagnose
Value developer time over machine time
Write abstract programs that generate code instead of writing code by hand
Prototype software before polishing it
Write flexible and open programs
Make the program and protocols extensible.
This is what KISS stands for: think about creating simple solutions to last. Your methods should be like a hammer: fit for purpose and hard to break.
How to achieve that? Start small and think about how your process is layered. Work from general to concrete, but when you’re at a high layer of abstraction - don’t put the low-level code into the same function. Create a separate function for every bit that seems complex and name it well. Do it again and again until every single thing becomes simple and clean.