KISS Principle: Make It Simple vs. Do It Simple

Making things simple is not the same as doing things simple. Unfortunately, this is not a simple message to get across.

Here's my personal quote of today. It is a bit complicated, but just read it twice and I'm sure you will understand it:

It is complicated to build stuff that is simple.
It is simple to build stuff that is complicated.

There's also a more famous quote by Mark Twain, which is a lot simpler:

I didn't have time to write a short letter, so I wrote a long one instead.

Mark Twain's quote is shorter than mine, although I'm sure it cost him more time. But no matter which quote you like best, what is true for writers is also true for programmers. It takes more time to make things that are simple.

The KISS Principle

In software projects there are two very important and very different notions about simplicity:

1. Work carried out in a project must be kept as simple as possible. (Do It Simple)
2. A product must be as simple as possible for its users. (Make It Simple)

Both are variants of the KISS principle (Keep It Simple, Stupid!), but they are applied very differently, which makes it a bit complicated. In the first case it is applied to the work performed, to minimize production costs, while in the second it is applied to the product, to minimize frustration costs. Many people don't seem to realize that Do It Simple conflicts Make It Simple, although both seem to be valid applications of the Keep It Simple principle. This has created a lot of confusion, and it hasn't made communication any simpler!

Creating things that are simple to use is at odds with the need to keep the work itself simple. When people tell me to "Keep It Simple", I am left wondering… Do they want me to do my work the simple way? Or do they want me to do it the complicated way, so that the results are simple? The Mark Twain quote came to my mind no less than three times while reading some blogs, articles and magazines before writing this blog post:

Simple Work <> Simple Products

Ed Yourdon complained about the difficulties he faced when adjusting the time in his car for Daylight Savings Time. Though I agree that user interfaces for changing time in many devices is a real pain, I can also understand why. Many manufacturers prioritize Do It Simple (design of a clock) over Make It Simple (usage of the clock). — After all, the ease with which one can adjust the clock in a car is usually not the main motivation for selecting one car brand over another.

I once got into a bit of a fight (verbally) with Chuck Allison, the writer of an article on complexity in software. Among other things, he writes that we can simplify the creation of software by adding additional layers of abstractions. He named high-level languages as one example. However, my claim is that this may be true for the users (the simple programmers like me), but it makes things very, very complicated for those enabling such an abstraction layer (the poor souls who build compilers).

Wired once had an article on 37signals, the guys behind Ruby on Rails, who apparently claim that developers should try and keep things simple. But what do they mean? It is said that they are snubbing people who have a hard time getting Ruby on Rails to do what they want. Wired Magazine says: "Now, critics argue, the pair's reactionary embrace of all things minimal has made their products less useful […]" In my terminology "less useful" might indicate having prioritized Do It Simple over Make It Simple.

Do It Simple or Make It Simple, But Not Both

I have always thought that Do It Simple conflicts Make It Simple. Though both have their place and value, you cannot have one's cake and eat it too. Unfortunately, this is a complicated message to get across, and I'm afraid this blog entry was written in just under an hour. It could probably be simplified, if I only had more time. Maybe there's a bit of Mark Twain in me right now. I didn't have time to write a short blog entry, so I wrote a long one instead.

Jurgen Appelo is an award-winning speaker, trainer, and author of Management 3.0, a management book for software development. You can hire him as a speaker or trainer, to add some spice to your discussions, workshops, or conferences.