views:

323

answers:

10

In my programming life I work with the principle "K.I.S.S." - keep it simple stupid. This works out pretty well for me although the projects and tasks get even more complicated (at least for me in my project life). Do you use this principle? Why? Why not? Do you prosper from kiss or do you think this is impossible?

+8  A: 

Yes, it plays a major role. We do Test-Driven Development here, so we write the tests for only what the requirements state. That way we only write code that we need, that is executed.

Beyond that, we all strive to keep things simple in general; complications lead to errors. We prefer to write less code to solve the problem (this doesn't mean using as many hacks to get fewer lines of code). Sometimes we have to do difficult and complicated things, but we try to encapsulate the yuckiness into its own class.

And the "stupid" part is to remind us all that we're not as good as we think we are :)

The net result is that most bugs are mostly simple to debug.

Ed Schwehm
A: 

I constantly strive for simple solutions, and often refactor code with the expressed intent of simplifying it typically prior to adding new features. Simple is easier to test, and usually there is less of it. Less effort means quicker turn-around.

/Allan

Allan Wind
A: 

A good implementation of K.I.S.S is not to use more than 3 levels of nesting.

Generally that's about where people start getting confused, and you should probably try put a function in instead.

Tasks and projects on the other hand will always get complicated. Just using K.I.S.S. for the programming side of things will make your life easier.

( You may have to write the same code 3 times to get it simple enough and good enough however )

Kent Fredric
+2  A: 

Yes. "Cleverness" is not generally approved of in our team. We try to be "clever enough" but no more clever.

Code which tries to be "clever" generally only achieves:

  • Unmaintainability, because it's cleverer than its author
  • Failure in edge cases, because it's not QUITE clever enough

For example, rather than setting database network permissions automatically in the database setup component installer, it is left to the operations team to do manually (albeit by running a script they keep under source control), because the code to do it automatically would be slightly too clever. It would work perfectly until someone changed the IP address numbering scheme or something.

MarkR
A: 
Corey Goldberg
+1  A: 

Keeping everything simple, is actually a lot more complex than the alternative of introducing complexity when it is required.

The opposing extremes are actually more similar than first glance -- you'll know of coders who get nothing done trying to simplify everything, and other coders who get nothing done trying to make it as complex as they can.

Richard Franks
+1  A: 

The K.I.S.S. is very important in my eyes. Simple and small functions are easy to read and to understand and tend to be less error-prone.

But I also saw code, where some one used nested ternary conditionals instead of if-then-else statements, which might be hard to read in some cases. Before the code starts to get unclear, I prefer to spend some "extra" lines of code. Even simple line breaks might help to make the code easier to understand.

koschi
+1  A: 

The main way in which I strive to keep things simple is to assure that functions fit on one screen in the IDE. This is a novel approach at my current gig, but it is bleeding out into the rest of my team and I have gotten comments from other developers noting that they prefer to debug my code than their own.

clweeks
+1  A: 

KISS plays THE role. Sometimes I feel like I'm fighting an uphill battle to keep things simple, but it sure is better than the alternative.

Jeremy Cantrell
+1  A: 

Everything can benefit from the KISS methodology just as they can in life. When explaining the code to a new developer it helps if the design and flow is exactly that, simple. It can clear up all kinds of caveats from having to remember what you did 6 months ago to being able to implement new features.

When it comes to the end of the day you want to know that people can understand what you have done and you want to have a user that likes it as well as being able to understand it yourself. All of these things benefit from a K.I.S.S approach.

Charlie Oliver