How 'simple' is a real KISS solution? [closed]

Question

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.

Thanks!

Answer 1

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

Answer 2

Scenario

You need to cut and pinch.

Solution A: Not KISS

Solution B: KISS

---

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.

Answer 3

"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.

Answer 4

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).

Answer 5

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.

Answer 6

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."

Answer 7

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

No.

Answer 8

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.