The year was 1960 and the U.S. Navy was immersed in the design and construction of a new jet aircraft; however, they wanted to do it differently. As such, they had challenged their engineers to create the aircraft in such a way that an average mechanic in the field (under combat conditions) could repair it with only a limited set of tools.

That challenge became a design principle for the U.S. Nav that is known today as: Keep it simple stupid (or KISS). Yes, without a comma. Here, the "stupid" refers to the relationship between the way things break and the sophistication available to repair them. Not the person.

But it turns out that keeping things simple is actually very challenging. Removing the unnecessary parts and focusing only on the bare necessities is difficult. Within software engineering, you could say that we typically do just the opposite. We clutter our code, infrastructure, tool-chains, etc. because it is "cool" to do so or to follow the latest trend. But By doing this, we lose sight of the primary purpose of building MVPs: which is to solve a current problem. Moreover, here it is quite important that anyone can fix a bug, or reboot the infrastructure; because sh** will happen and you might not have anyone to help you out.

A typical scenario that leads to cluttered code is the following: discussing a new feature. At some point, someone will say: hey, we should design this for when we have 10K users. You have not even launched the project, and yet you're already overcomplicating the code through this design process.

We tend to forget the KISS design principle. Actually, since its inception, similar approaches have been encouraged in software engineering to try to get people to keep things simple. 

In 1978, the Unix Philosophy was born. It recommends building simple, short, clear, modular, and extensible code that can be easily maintained and repurposed by developers other than its creators. Sound familiar?

Almost ten years later, in 1989, the Worse is Better design principle was coined by Richard P. Gabriel, the creator of the programming language LISP. Richard clearly stated that designing software should be kept simple and that it is the most important consideration in a design.

Again, almost ten years later, in 1998, a new recommendation was shared: You aren't gonna need it by eXtreme Programming. The idea is that you should "only implement things when you actually need them, never when you just foresee that you might need them." 

Reflecting on this trend, it is clear that, over the years, many people have been really interested in keeping things simple. Also, most of them have built some amazing systems, from jet aircrafts ( Lockheed U-2 and SR-71 Blackbird ) to operating systems (UNIX). And all of them share a common goal: to allow anyone involved with the system, machine, or code to be able to read it, understand it, and fix it.

At the end of the day, the less code we write, the fewer errors it will have. Also, the easier it will be to maintain and get new people on board. As software engineer Martin Fowler said: "Any fool can write code that a computer can understand. Good programmers write code that humans can understand."

In thermodynamics, the second law states that: the total entropy of an isolated system can never decrease over time. Thus, all of our systems will inevitably get more complex over time. So my advice is to start small, keep things simple, and avoid letting entropy into your project too soon.

Since I joined B4Motion as the CTO, I have applied these principles to our companies and our way of working. The aim? To keep things simple stupid. To allow any new members of the company to be able to jump in and write code as quickly as possible. To remove unnecessary complexities, to make the code more inclusive, or to paraphrase Fowler: to write code that humans can understand.

Daniel Lombraña

CTO at B4Motion