Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

The KISS principle is a highly quoted design mantra. The aim of this principle is to stamp out unnecessary complexity on a project. This is a good thing, saving time, energy and money. It can lead to a relatively stress free implementation and a simple, elegant, maintainable end product.

A lot of discussion on KISS provides mechanisms to simplify requirements, design and implementation. Things that spring to mind include: avoid scope creep; simple obvious design and code; minimal run-time dependencies; refactoring to maintain simplicity; etc.

However there are a lot of implicit things that we do to KISS. Examples: small team sizes; minimal management layers; tidy desk; mastery of a single IDE; clear concise error messages; scripts to automate/encapsulate tasks; etc

What KISS practices do you apply? How have they benefited you? I'm especially interested in non-obvious practices.

share|improve this question

closed as not constructive by Thomas Owens Oct 10 '12 at 17:05

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.If this question can be reworded to fit the rules in the help center, please edit the question.

    
Checklist questions don't meet the guidelines to asking questions on this site. Read the site's FAQ and the guidelines and edit this question. –  Walter Jan 13 '11 at 12:50
1  
Keep it simple, Stupid! :) –  pramodc84 Jan 13 '11 at 12:50
1  
Updated question based on Walter's comment. –  Conor Jan 13 '11 at 13:05
24  
And remember to keep your kisses DRY. ^^ –  gablin Jan 13 '11 at 13:32
2  
A side question: what do you think about KISS in programming language design? Which languages are more KISS oriented and which ones less? –  Giorgio Sep 8 '11 at 20:07
show 1 more comment

10 Answers 10

It's all about choice points and applying the Occam's Razzor thing.

  1. Choose the simple solution : When you have choice between several valid (proved to be correct) solutions to one problem, choose the solution that is the most obvious to a)understand b)implement; once done, you can see if it scales correctly with the rest of the project and if it don't, you already have a simplist solution working so it's easier to build over it.
  2. There is only one way to do it : When you want to provide a service (a class function or a system), make it so simple (but not simplist) that there only one way to use this service. As there is only one way, that way have to be correct.
  3. Make it obvious : When you write a non-trivial algorithm or system, work the code until it's just OBVIOUS. Domain-specific informations are another orthogonal aspect.
  4. Short and concise : When you have several way to write something, use the shortest form, assuming it don't break 1.. Also, prefer one or maximum two words to describe a concept or action (class or functions or likes).
share|improve this answer
    
I agree with this. If you can look at a solution and say "This just doesn't feel right", you can probably simplify it and keep it simple. –  gablin Jan 13 '11 at 13:31
add comment

KISS means that the code is simple, however I think it's a common misconception that programmers feel this also means it's simple to write. It requires you to remind yourself of your objectives and what the point of any given objective is.

If you pass over a class you've already created and find yourself taking more than a couple seconds to remember what a given method does, it doesn't belong there. It should be simple enough that the method of any given object is self-describing. It's also a contract, meaning while it's tempting to throw in code that may not belong because it gets called, you don't. You figure out another way to handle it, even if it requires you to change the project design.

That's what it means to adopt KISS as a programming style, and it takes years to perfect. Once you have, you write programs which put your old ones to shame, and you don't like your colleagues to touch your work. :)

share|improve this answer
5  
+1 for distinction between simple code and simple-to-write code –  Larry Coleman Jan 13 '11 at 13:57
    
There is an interesting presentation by Rich Hickey (designer of Clojure) Simple Made Easy about this distinction between "simple" and "simple to write" a.k.a. "easy". –  Jan Hudec Oct 10 '12 at 12:57
    
@JanHudec, thanks for sharing. Very interesting presentation. –  Neil Oct 24 '12 at 9:58
add comment

You start with a simple application architecture. Develop for the problems you need to solve today and not try to account for any contingency like a world war, hadron collider explosion or an alien invasion.

avoid scope creep; simple obvious design and code; minimal run-time dependencies; refactoring to maintain simplicity; etc.

small team sizes; minimal management layers; tidy desk; mastery of a single IDE; clear concise error messages; scripts to automate/encapsulate tasks; etc

What you've described are rather KISS instances. They are good (except tidy desk) but it begins much higher. It is a team philosophy for doing all things. And I dare to say it begins with an individual's personality. Some can keep things in life simple, some are always going for unnecessary complications. Find out first how you are. :)

share|improve this answer
1  
+1. This answer is an example of KISS and you nailed it with "it begins with an individual's personality." Many people thrive on complexity and pass on the simple solution as too simplistic. –  kirk.burleson Sep 9 '11 at 2:34
add comment

My experience is that writing simple code is like good writing in general. There are well-defined principles for each, but you wouldn't expect your first draft of a novel to be perfect. Similarly, your first draft of the program doesn't have to be perfect either.

I typically write something and get it working, then go back through the code and evaluate how well it's organized and whether it's easy to follow. In the course of that evaluation, I can typically spot places that could be organized better, and places that could be simplified.

share|improve this answer
    
I do things similarly, except that I'll go back and refactor parts without having the whole thing working, or even having the part I'm currently writing working. Refactoring like this helps me think things through -- I often don't or even can't think everything through before starting. Paul Graham points out in an essay the differences between sketching or working in stone, and I'm definitely a sketcher. Such iterative refinements help me make my code base smaller and more concise. –  paul Oct 4 '12 at 17:04
add comment

Here are some guidelines I follow when coding. I consider them as being KISS guidelines, even though I haven't taken them from any book mentioning them as such.

  • Avoid complex programming constructs that, while they may be cool, are more difficult to manage and error prone. I always use only constructs I am very familiar with, especially for production code.

  • Avoid complex expressions or statements: I prefer to split a complex expression into small steps and write them out explicitly: this makes correcting and debugging code much easier.

  • Avoid too much implicit information in the code, e.g. I write conversion constructors explicitly so that I am sure that I and the compiler mean the same thing. (Sometimes the code looks simple because it is concise, but the complexity is hidden.)

  • Use a minimal set of programming idioms that just does the job. While using many different idioms can make programming more exciting, I think that using only a few of them makes the code more readable.

  • Avoid long and complex functions / methods. Instead, I try to write short functions whose body fits almost always in one screen, with a well-defined small computation. I try to achieve complexity by function composition.

  • Only implement some general mechanism if I am sure that I am going to use it at least 3 or 4 times. E.g. I do not implement some cool template class if I am going to instantiate it only 2 times.

I could write more examples but I think KISS is rather an attitude towards problem solving: avoid complexity unless you see a good practical reason for it. The problem at hand is normally complex enough, avoid any unnecessary complexity in the solution. Do not add complexity just because it feels cool do to so: you customer will not see your code. :-)

share|improve this answer
add comment

Question all requirements, assumptions and design decisions such that you focus on solving problems that you know (or can be pretty damn certain) really exist.

Too much time is wasted and complexity introduced by things which are nice to have rather than important or which deal with situations and scenarios which may never come about.

One of the things that most struck me about XP when I heard Kent Beck speaking about it was the idea that "it's hard enough to solve the problems you have today, without trying to guess what problems you might have tomorrow and solve them too".

I wince when I think about the amount of spaghetti code I've had to deal with which was designed to make the solution generic and future proof against a million things which never happened and would never happen.

share|improve this answer
    
Everything should be as simple as possible, and no simpler. Is it mean to point out that when Kent Beck invented Extreme Programming, the project was cancelled before being put into full production? Maybe some of "tomorrow's problems" needed attention today, after all? –  MarkJ Oct 4 '12 at 15:35
    
@MarkJ - Given that it was cancelled after a merger I'm not sure it's fair to blame in on XP. The levels of politics that mergers bring about can cause all sorts of good and bad decisions. But more pertinently I guess the real problem is that requirements are hard and there are as many people pushing to over simplify as there are to over complicate. –  Jon Hopkins Oct 5 '12 at 14:26
add comment

With the lightning fast evolution and obsolescence of software, it is extremely work-saving down the line to split software into as many independently useful pieces as possible, use open and human-readable file formats, and choose the simplest format that does the job.

share|improve this answer
    
You mean like Unix with its "pass everything as stings as this is the universal interface" ? –  Christopher Mahan Sep 9 '11 at 23:49
    
@Christopher: Kind of. But it's not always optimal, since not everything is useful to represent as strings (blobs, booleans, and objects connected in a non-hierarchical way). –  l0b0 Sep 12 '11 at 14:38
    
Indeed, this is why unix people eschew binary formats. –  Christopher Mahan Sep 12 '11 at 18:10
add comment

Just to add a couple of other examples:

YAGNI comes to mind along with the idea of, "Just do what is asked, no more and no less." If it wasn't in the requirement then it may be worth leaving out to keep something to be just what was requested and not trying to anticipate what someone wants.

Scrum tends to feel like it has some KISS atttributes as the daily stand-up is a fairly quick and straightforward meeting of what happened, what will happen and what would stop that from happening.

share|improve this answer
add comment

For me, KISS means not using an IDE and keeping the program to less than 20 lines of code, not using OOP unless I can't do without, and writing the code to paper before typing it in the computer. If I can't correctly step through the code in my head while staring at the ceiling, it's not Simple.

share|improve this answer
1  
Isn't that a bit...extreme? –  Tudorizer Sep 9 '11 at 8:56
    
Absolutely. It's hard coding like that. But it does yield good results. –  Christopher Mahan Sep 9 '11 at 15:37
add comment

Do one thing at a time. Interruptions, task switching, and multitasking all detract from the focus needed to do good work. Multitasking is especially insidious, since recent research shows that while it feels great to multitask, people are less productive when doing so.

Don't Repeat Yourself. A surprisingly versatile principle. It applies to code, database design, documentation, and automation of work procedures.

If I'm doing anything a second time (like setting up a SVN repository), I document it in the company wiki. That way, every time someone asks me how to do it, I point to the wiki instead of repeating myself. Even when I need to do it myself again, I can just cut & paste the set of commandline instructions, instead of doing it all by hand again.

share|improve this answer
add comment

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