Explained

## What is KISS and What Does it Stand For?

"Keep It Simple, Stupid!" is a design principle which is very commonly referred to in software development, but is applicable to pretty much any system or process in any industry.

## What Does the KISS Principle Try to Achieve?

Once you know what it stands for, KISS becomes almost self-explanatory: it's often better to try and keep things simple. In principle, simpler systems work better than overly complex ones due to the massively increased scope for error in complicated systems.

It sounds kind of obvious, but you should try to avoid _unnecessary_ code complexity where possible and aim to design with simplicity in mind. I highlight the word "unnecessary" because you're never going to be able to avoid _all_ complexity, but you should try not to over-complicate things where possible.

## How Can I Keep Things Simple?

### Break It Down

Being able to break down your problems into smaller and smaller ones is one of the best ways to simplify your code. Have you ever seen a function like this?

```js
const doSomethingAndThenSomethingElse = () => { ... }
```

The "And" in the name of that function is an immediate red flag that it's got too much responsibility and needs to be broken down further. The aim is to write smaller classes and functions which only solve _one single problem_. If you have a lot of conditions in your function, break these out into smaller functions.

### Don't Solve Problems You Don't Have

It can be tempting to go overboard and try to future-proof your code to the fullest extent, catering for all future eventualities and possibilities. The problem with that is you will end up introducing complexity with no immediate value. It could result in issues coming to the surface which need complicated bug fixes, wasting time and energy on something you didn't need in the first place. This is actually a principle in itself: YAGNI (You Ain't Gonna Need It) which compliments the KISS principle rather well.

## What Are the Benefits of Keeping Things Simple?

### Speed and Flexibility

I'm going to resort to the much-loved the LEGO analogy: when you manage to have your many classes and functions which all solve their individual problems it's like having lots of different LEGO bricks. You can stack them together quickly to create something new and easily switch out one brick for another to achieve different outcomes. This ultimately results in being able to solve new problems faster as well as diagnosing and fixing existing issues more efficiently.

### Maintainability

Furthering what I've talked about above, your code should also result in being more easily readable and understandable by anyone who is new to the codebase. That is a big advantage when thinking about maintainability; lowering that mental barrier to entry means it won't take long for other developers to figure out how best fix issues or extend the codebase to add new features.

### Code Quality

You should find that by focusing writing functions with a single purpose, you will in turn be able to pay more attention to how you can perform the required task in the most efficient and concise way possible to produce the best code for the job.

Testing becomes easier too! You should be able to write bullet-proof unit tests which make sure your functions do what you need them to in all situations. The test cases are always going to be simpler when your functions don't try to do too much.

### Scalability

Going back to the LEGO analogy, the theory is that you can keep adding bricks to scale up and up as much as you need. I realise the reality is never that simple, but it goes some way to helping avoid the issues scaling up more complex systems.

### KISS Can Be Subjective

Which of the following would you describe as "simplest"?

```ts
const getWeekday = (month: number) => {
    switch (month) {
        case 1:
            return "January";
        case 2:
            return "February";
        case 3:
            return "March";
        case 4:
            return "April";
        case 5:
            return "May";
        case 6:
            return "June";
        case 7:
            return "July";
        case 8:
            return "August";
        case 9:
            return "September";
        case 10:
            return "October";
        case 11:
            return "November";
        case 12:
            return "December";
        default:
            throw new Error("month must be in range 1 - 12");
    }
};
```

```ts
const getWeekday = (month: number) => {
    if (month < 1 || month > 7)
        throw new Error("month must be in range 1 - 12");

    return [
        "January",
        "February",
        "March",
        "April",
        "May",
        "June",
        "July",
        "August",
        "September",
        "October",
        "November",
        "December",
    ][month - 1];
};
```

Whichever one you prefer, you can bet it's not going to be the same for everyone! It doesn't necessarily matter and it's not something to get too caught up in, but it's something to be aware of.

## Closing Comments

One thing worth noting is that you may find that principles like KISS can conflict with other principles. For example, DRY (Don't Repeat Yourself) in its most basic over-simplified definition states that you should never duplicate code, however there will be times where a little bit of code duplication actually reduces complexity and saves you headaches in the future.

"Keep It Simple, Stupid!" is a design principle which encourages you to focus on simplicity and avoid unnecessary over-complication.

Explained: What is the KISS Principle?


## Defining Abstraction

Programmers often use the word "abstraction" when talking about their code but it's not a term new programmers are likely to have come across and understand.

### The Dictionary Definition

<blockquote>
    "The act of considering something as a general quality or characteristic, apart from concrete realities, specific objects, or actual instances."
    <footer><cite>
      <a href="https://www.dictionary.com/browse/abstraction" rel="noopener" target="_blank" title="Dictionary.com definition of abstraction">dictionary.com</a>
      </cite></footer>
</blockquote>

I don't know about you, but I don't find this definition particularly helpful. Let's try and make it a bit easier to digest.

### My Alternative Definition

Here's my attempt to redefine "abstraction" to make it simpler and more directly applicable to our use case: programming.

<blockquote>
    "Providing a label to a piece of code that accurately describes the purpose and actions of that logic."
</blockquote>

I think that's a much easier to understand. The first thing you might think to yourself is "That just sounds like a description of variables, functions, and classes"...and you would be right! These can all be forms of abstraction. We'll have a look at each of these a bit later.

## Why Do We Want/Need to Abstract Anything?

Breaking-up code into smaller labelled chunks helps us write clean code which is easy to read, maintain and re-use.

### Focusing on What We Care About

Abstraction helps us focus on results; we don't have to worry about _how_ something is done, we only care about _what_ the result is.

### Readable Code

We reduce complexity by placing logic behind layered abstractions. This means at the top-level we only see the top-level abstractions, which ultimately makes the code much easier to read. This should become a little clearer when we look at some examples.

### Reusable Code

Once code has been abstracted we can use it throughout a project again and again. It means that we only have to write the code once instead of repeating ourselves which has a lot of benefits (which is a topic for another time).

## Examples

I'm going to use "making a BLT sandwich" as a contrived example.

### Variables

We have a bunch of variables containing a bunch of values, like this:

```js
const breadState = "buttered";
const baconState = "raw";
const lettuceState = "washed";
const tomatoState = "washed";
```

We can see all of the states of all the necessary ingredients for our sandwich. Now we want to know whether we can assemble it:

```js
const isReadyToAssemble =
    breadState === "buttered" &&
    baconState === "cooked" &&
    lettuceState === "washed" &&
    tomatoState === "sliced";
```

`isReadyToAssemble` is an abstraction. Referring back to my earlier definition, `isReadyToAssemble` is the _label_ which describes of whether all of ingredients are ready for sandwich assembly. Now, further down in our code, we don't have to concern ourselves with _how_ we know it's ready, we just know that `isReadyToAssemble` will tell us; that's the beauty of abstraction - overlaying more complex logic with a simple label.

If it helps you can relate this to the real-life equivalent situation. Which of the following questions are you more likely to ask?

1. "Is the bread buttered and the bacon cooked and the lettuce washed and the tomato sliced for me to assemble the sandwich?"
2. "Are all of the ingredients ready for me to assemble the sandwich?"

My guess is that you're a bit more in-line with number 2. So you see, you abstract everyday without even realising!

```js
if (isReadyToAssemble) {
    const sandwich = assembleBltSandwich(ingredients);
}
```

And this leads us nicely on to our next example...

### Functions

Similar to variables but containing more complex logic.

We can use `assembleBltSandwich()` as our example here. We know that we can call this function and it will return us an assembled sandwich. All of the logic describing _how_ the sandwich is made is hidden away inside that function.

We could imagine that the contents of `assembleBltSandwich()` looks something like this:

```js
function assembleBltSandwich(ingredients) {
    return layBreadButterSideUp(ingredients.bread.sliceOne)
        .then(() => addMayo(ingredients.mayo))
        .then(() => addBacon(ingredients.bacon))
        .then(() => addTomato(ingredients.tomato)) // <-- Tip: never let the tomato touch the bread, it makes it soggy and horrible
        .then(() => addLettuce(ingredients.lettuce))
        .then(() => addMayo(ingredients.mayo))
        .then(() => layBreadButterSideDown(ingredients.bread.sliceTwo));
}
```

Here we can once again see that some of the logic is abstracted further into functions like `addBacon()`. The result is layer upon layer of abstraction, with the bottom layers doing the heavy logic and the top layers basically just acting as labelled wrappers to make things easier.

### Classes

I won't go too in-depth with this because I think you're getting the idea by now. You can abstract details and actions of a sandwich into a `BltSandwich` class like so:

```js
class BltSandwich extends Sandwich { // <-- You don't have to worry about what's in the base Sandwich class for this example.
    public ingredients;

    constructor(ingredients) {
        super(ingredients);
    }

    public prepare() {
        ...

        return this;
    }

    public assemble() {
        ...

        return this;
    }
}
```

This is a further abstraction on top of everything we've already covered. So when we want to prepare and assemble a sandwich now, all we have to do is this:

```js
const ingredients = {
    bread,
    butter,
    bacon,
    lettuce,
    tomato,
    mayo,
};

const sandwich = new BltSandwich(ingredients).prepare().assemble();
```

All of the logic is nicely contained inside the class' public methods and we can just enjoy our lovely sandwich.

## Abstract with Caution!

There are a couple of things to be aware of when thinking about introducing a new abstraction into your code.

### Over-Abstraction

So abstraction is great, we should use it all the time for everything, right!? Well...not exactly.

It's easy to go overboard and over-abstract in an attempt to make code super generic and re-usable. You end up losing clarity on the feature you're building because you try to make it work for every possible use case and not the one(s) that you've been presented with. It makes it difficult for anyone else to understand what you've done and why.

This topic could easily be a whole blog post in itself, which I hope I'll be able to write someday.

### The Wrong Abstraction

Creating the wrong abstractions results in code which is difficult to understand and even more difficult to work with.

The common scenario is that you have two pieces of code which are doing similar things in multiple different places and, because you want clean code, you merge them together into a generic method which takes a bunch of arguments to make sure it does the right thing depending on there the method is called.

Abstraction complete. Sounds fine, right? But now one of a few things could happen:

1. New requirement: do something exactly the same in a different place
2. New requirement: do something mostly similar in a different place
3. New requirement: change the way it works for some of the places but not others

Now you might be able to spot some problems:

1. There's no problem here, but in my experience it's not often you'll get asked to do something which is a carbon copy of something else.
2. So you need to modify your abstraction and pass it more arguments so that it'll do what you need it to do in this new case. That's going to make it look messy and confusing as you keep adding things into that method.
3. So you need to modify your abstraction whilst making sure you don't introduce any issues with the other existing code. That's always easier said than done.

So there is an argument here that the logic should not have been abstracted together in the first place, it would have been better to have isolated duplicate code which means it's easy to modify without causing issues with existing code.

It's almost impossible to foresee changes in the future so you can't plan for everything, but just try to ask yourself whether the abstraction makes logical sense - don't just do it to keep your code [DRY](https://en.wikipedia.org/wiki/Don%27t_repeat_yourself "Don't Repeat Yourself: Wikipedia").

<br />
<hr />
<br />

**Update (27/07/2020):** I recently came across [The WET Codebase](https://www.deconstructconf.com/2019/dan-abramov-the-wet-codebase "The WET Codebase: A talk by Dan Abramov"): a talk by [Dan Abramov](https://twitter.com/dan_abramov "Dan Abramov on Twitter") via [a post on his blog](https://overreacted.io/the-wet-codebase/ "The WET Codebase: A blog post by Dan Abramov"). The talk explains a lot if what I've written above very well with some nice clear visuals; it's worth a watch! Also, if you're a fan of [React](https://reactjs.org/ "React JS") you'll love the rest of his blog!


Abstraction is not as complicated as you might first think, especially because you already abstract every day without even thinking about it!

Series: "Explained"

Explained: What is the KISS Principle?

Explained: What Is Abstraction?