We, humans that is, love to complicate things and it seems to come naturally without too much effort. The longer we work with a given project, the more complex it becomes. I am not just talking about software engineering, but pretty much anything we undertake. Yet how does this seem to happen?

The short answer is that we slowly turn up the heat on ourselves, each little turn feeling like a natural and necessary evolution. The more we get into something, the less input we take from the outside, feeding on our shared enthusiasm and excitement to create something beautiful. We’re boiling ourselves (along with the mythical frog).

There is a well known phrase in software circles, borrowed from the US Navy from 1960, that is known as the KISS principle.

Keep It Simple, Stupid

If there is any principle you should keep in mind at all times, then it will be this one. No matter if you are an enterprise architect laying down the foundation for a complete company, or developing a small utility class, the principle should be first and forefront in your mind.

The essence of KISS is simplicity. A simple system is easy to build. Easier to fix. Easier to adapt. Easier to use and educate. Within software, it is also easier to debug. The less code you have the less chance there is something to go wrong.

I like to think of software complexity like moving parts in a mechanical device. The less moving parts, the less wear’n’tear there is going to be and therefore less chance of it breaking. There is a reason cars from the 1960’s and 1970’s are still running today – not many pieces in them. It is easy to pop the hood, change the oil, fix the timing belt, or whatever else. Contrast that to a modern car with so many microprocessors and interconnected systems. I was brought up doing my own servicing, but today, I don’t even open the hood and pretend I know what I am looking at! It’s too damn complicated.

So how can we KISS our software? Let us look at some practical tips that can be applied to keep things as simple as possible.

---

1. Code for readability, not performance
   Clever code is complex code by its nature. Doing something in a single line, because a quirk of the language permits, should be avoided at all costs. Use well known patterns and resist the urge to optimize too early on in the process. Getting it working first, and performance if at all required, can come at a later date if at all.
2. Don’t do too much in one step
   Functions/Classes should be narrow in their definition and feature set. Putting too much in a single class or method, makes that class have a low code cohesion (in other words focused on too many things at once). This makes the code hard to adapt and reuse.
3. Use names that make sense
   Make variables, functions, classes and files have names that tell you what it is they are doing. Gone are the days where we were constrained to only 8 characters – life a little. Conversely you don’t need to go writing a whole paragraph with camel-case and using that. Give the reader a clue as to what is happening.
4. Avoid ‘if’ inside an ‘if’ inside an ‘if’ inside an ‘if’ …
   Here is a tip, if you have to use your horizontal scrollbar to read code, then you have gone and nested too many logical ‘if’ statements. Too many nested logical blocks makes it real hard to test code that reaches them, and the last thing we want is to make it harder to test.
5. Assume dirty data
   I like to lay out my tools/ingredients first before I do something. In code, I like to get all my data validation and checks done right at the start of a function. Assume you are going to get bad data (nulls, strings instead of numbers etc.) and take the necessary action there and then. The vast majority of bugs originate because the developer never expected bad data.
6. Stop re-inventing the wheel
   The more code we have the more there is to go wrong, so start reusing code instead of always developing it. Break out methods into a common library, pull in a well known 3rd party open source library. The less code you produce the better.

---

Let me be clear, KISS is hard. Everyone sets out with good intentions and before you know it, boom, we’re looking at a whole bunch of spaghetti code and thoughts of scraping it all and rewriting comes up. It takes practice to hold yourself back and not get too clever. Go at something with a child like innocence, assuming nothing.

An exercise I like to do after finishing a block of code, is to read through it, out loud, as if you were presenting to a team about it. That simple little act, slows down your brain and lets you observe things you probably missed at the time of composition.

Remember, the business/user of your output, will take reliability and dependability over speed/performance and being clever, every single time.

Next time you produce something, and just before you hit the commit message, apply a little KISS and see if you can make it better.