I confess: I have a problem to "Keep It Simple and Short" most of the time because trying to make it according to the books I have read, design-patterns I have heard etc. gives me such an enthusiasm -an enthusiasm coming from the sense of that I am on the right path to a probable perfection.

On the other hand, yes, it puts an extra stress on me in terms of delivering the deadlines sometimes...

But whenever I say to myself, "Next time keep it simple, you stupid!" I find it quiet hard to make it "simple" when that next-time comes, because it starts to feel weird... and uncomfortable after a point.

Then I start to judge my understanding of 'simple'...

Does SIMPLE mean too short that it works but hard to maintain and extend?

Does SIMPLE mean breaking many of the OOP principles?

Does SIMPLE mean cheating?

Does SIMPLE mean just keeping the deadlines without no dealy? etc.

Actually, what is it?

Question is: Can you write the EXACT definition of SIMPLE in terms of KISS principle? -if there is.


  • 4
    It's "Keep it simple, stupid!", not short. and after writing that, i saw that you actually know it but there isnt any delete comment link on mobile p.se... – yannis Oct 25 '11 at 17:25
  • 4
    I've never found something so short it was hard to extend. I have found LOTS of things that were massive monstrosities that were almost unmaintainable because changing one thing broke everything else. – Ben Brocka Oct 25 '11 at 17:56
  • 1
    I think the mistake most people make in trying to understand KISS is that they think the solution should be so simple,it's self evident. The truth is that finding a simple solution is everything but simple. It's really hard!!! Once you have found it, everybody thinks "oh, it is so obvious, why didn't I see it before?" – Treb Oct 25 '11 at 19:51
  • 2
    Good KISSing is hard to explain or define precisely, but once you get it right, you'll know. Just keep practicing! – Cascabel Oct 25 '11 at 19:58
  • 1
    I'm sorry this was migrated here instead of just closed outright, but this is hilariously off-topic here. – user8 Oct 25 '11 at 20:37

Let's learn a french KISS:

La perfection est atteinte, non pas lorsqu'il n'y a plus rien à ajouter, mais lorsqu'il n'y a plus rien à retirer. — Antoine de Saint-Exupéry

Which is translated to:

Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away. — Antoine de Saint-Exupéry

  • 2
    Should be "Perfection is when there is nothing to remove" – normanthesquid Oct 25 '11 at 18:33
  • 2
    This is a great quote but it lacks practical advice. – c_maker Oct 25 '11 at 19:02
  • 2
    You could make this answer more simple (aka more perfect) if you remove the French part. :) – Phil Oct 25 '11 at 20:17
  • 1
    @Phil: Au contraire, mon ami. – Gilbert Le Blanc Oct 26 '11 at 15:38


You need to cut and pinch.

Solution A: Not KISS

enter image description here

Solution B: KISS

enter image description here enter image description here

As for an exact definition: It's hard to define an absolute scale for measuring simplicity. Mostly because true simplicity precludes true understanding of the problem at hand, and that's rarely attainable. But let's say that solution A and B illustrate the difference between solutions that tend towards overcomplication and simplicity respectively.

  • This made me smile. – c_maker Oct 25 '11 at 18:51
  • Very violent, is it not! – NoChance Oct 25 '11 at 19:53
  • 2
    It is not. My kitten sleeps with it. Therefore it is nonviolent. – Thomas Eding Oct 25 '11 at 20:19

"Make things as simple as possible, but not simpler" -Einstein

Keeping code as simple as possible, but not simpler depends on the problem being solved. As long as the problem being solved tends to change, so does KISS.

There is a balance between over-engineering (oh man this looks like a great place to show off my Design Pattern skills!) and under-engineering (if only I used a factory I wouldn't have this coupling that caused me to make 20 code changes...). The goal is maintainability.

  • 1
    "Keep your cyclomatic complexity to the value it ought to be, and no other value". "Buy a house with a loan to value ratio as low as you reasonably can, but no lower". "Eat as good a breakfast as you can, but no better". "Buy as low and sell as high as you can, but no lower/higher". "Grow as tall as you can, but no taller". "Make variable names as meaningful as possible, but no meaning-fuller". "Give as high a percentage of effort as you can, but no higher". "There is no 'I' in 'team', but there's one in 'higher'". "Stop and smell the roses, but only when there's roses". "Write commen – psr Oct 25 '11 at 18:16

Simple doesn't mean breaking good programming principles. In fact, it means more of the opposite.

Does SIMPLE mean too short that it works but hard to maintain and extend?

No. Being hard to maintain and extend are a big symptom of complexity. In fact, I find that making code extensible leads to simpler code, since you do not deal with every single case to begin with, you can keep the base code simpler.

Does SIMPLE mean breaking many of the OOP principles?

No. Most OOP principles are designed to keep code cleaner and more organized, which in the end, is simpler.

Does SIMPLE mean cheating?

No. writing hard to maintain code & hacks under the guise of keeping deadlines is.

Does SIMPLE mean just keeping the deadlines without no dealy? etc.

No. deadlines and the simplicity of your code are two separate issues. Writing simple code doesn't take any time longer to write (although it is a common misconception).

  • Maybe you think I suffer from that misconception, but I think that the ideal simple solution is not always the first thing to occur to us, so it does sometimes initially take longer to write simpler code - then later you make up that time and more by not having to deal with the complexity. – Cascabel Oct 25 '11 at 20:25

This is very tricky to explain because simple does not mean the same thing to everyone.

Example. Some devs think that ?: is simple but others think an if statement is better. When its down to this level, you cannot please everyone.

In general, simple means without complexity. In order to understand simplicity, we need to understand complexity.

There are two types of complexity:

Essential complexity refers to a situation where all reasonable solutions to a problem must be complicated (and possibly confusing) because the "simple" solutions would not adequately solve the problem. -- Wikipedia

Accidental complexity is complexity that arises in computer programs or their development process (computer programming) which is non-essential to the problem to be solved. -- Wikipedia

You can check essential complexity with the following questions:

Is this solution simple? Can I explain it to my peer in a span of a couple of minutes and they get it? Is there a simpler solution to the problem? If yes, are there any trade-offs between the complicated solution versus the simple one? Can we live with those trade-offs? For example, many programmers make a mistake of micro optimizing everything and their solution (and the code as well) becomes overly complicated.

Checking your accidental complexity:

Is the code simple? If I come back to it in three months, how long will it take for me to build the context in my brain so I can make the change I need to make? Is everything in my source code has a clear purpose and it conveys that purpose effectively to me and other developers? How hard is it to test my code? Usually the more complicated your code is, the harder it is to unit test, so I usually use this as a measure of complexity. You usually want small, well named and focused classes and methods. Design patterns usually help you achieve these as well.

If you find yourself wanting to use a design pattern just because you just read about it, it is probably going to introduce accidental complexity. If you find yourself wanting to put something in because you think 'its smart' it will probably introduce accidental complexity.

I hope this helps and do not forget: Simple does not mean EASY.

  • 1
    +1 for defining simplicity in terms of essential and accidental complexity. – Zach Oct 25 '11 at 19:40

I've always felt like the principles behind X11 ( http://en.wikipedia.org/wiki/X_Window_System#Principles ) were worth heeding. I do not always succeed in this goal.

Specifically, I keep having to remind myself ... "Do not add new functionality unless you know of some real application that will require it.", and "If you can get 90 percent of the desired effect for 10 percent of the work, use the simpler solution."


Question is: Can you write the EXACT definition of SIMPLE in terms of KISS principle? -if there is.


  • 3
    Not sure this should be an answer. If you can't give such a definition, then you shouldn't answer IMHO. If you think an exact definition is impossible in general, you should elaborate on the reasons. – back2dos Oct 25 '11 at 19:04
  • What I love about this answer is that it follows the KISS principle to the letter! +1 – Treb Oct 25 '11 at 19:45
  • simple can be really complicated sometimes. – GSto Oct 25 '11 at 20:37
  • @back2dos its the stronger claim; I don't go around posting "I don't know" answers. – Jeremy Oct 25 '11 at 20:42

Simple - in this particular context is the exact opposite to complex. Simple doesn't necessary mean: Every stupid minded person has to understand it - but you have to make sure, that you could understand it, even if you haven't written it yourself.

Complexity could be achieved by hard tyo understand references - get rid of those! Many files/classes linked to each other - no way! And complicated code (meaning: chained loops, multiple ITE layers, etc.) - nobody wants to read that.

In my opinion: It is very easy to add another function, in classes you can also add private functions, so you don't mess with the interface. So why don't use this advantage and limit you functions/procedures to 50 lines. Maybe even less. Get some meaningful names. In this way you render most comments obsolete. In this way your functions are easy to read, easy to modify/extend.

Of course...the last few sentences would have worked as: In classes there is the availability to define private functions, just use this possibility to split functions into 50 liners so it is be much more readable (don't forget good names, so you don't need to comment that much).

BUT: It is much more simple(!) to read everything if there is a fullstop which shows: I finished a thought, let's go on with the next one.

Thats what I would define as simple.

Not the answer you're looking for? Browse other questions tagged or ask your own question.