KISS: Keep It Simple, Stupid

The Kiss Principle: "Keep It Simple, Stupid"

What does KISS stand for?

The KISS is an abbreviation of Keep It Stupid Simple or Keep It Simple, Stupid

What does that mean?

This principle has been a key, and a huge success in my years of software engineering. A common problem among software engineers and developers today is that they tend to over complicate problems.
Typically when a developer is faced with a problem, they break it down into smaller pieces that they think they understand and then try to implement the solution in code. I would say 8 or 9 out of 10 developers make the mistake that they don't break down the problem into small enough or understandable enough pieces. This results in very complex implementations of even the most simple problems, another side effect is spagetthi code, something we tought only BASIC would do with its goto statements, but in Java this results in classes with 500-1000 lines of code, methods that each have several hundreds of lines.
This code clutter is a result of the developer realizing exception cases to his original solution while he is typing in code. These exception cases would have solved if the developer had broken down the problem further.

How will I benefit from KISS

• You will be able to solve more problems, faster.
• You will be able to produce code to solve complex problems in fewer lines of code
• You will be able to produce higher quality code
• You will be able to build larger systems, easier to maintain
• You're code base will be more flexible, easier to extend, modify or refactor when new requirements arrive
• You will be able to achieve more than you ever imagined
• You will be able to work in large development groups and large projects since all the code is stupid simple

How can I apply the KISS principle to my work

There are several steps to take, very simple, but could be challenging for some. As easy as it sounds, keeping it simple, is a matter of patience, mostly with yourself.

• Be Humble, don't think of yourself as a super genius, this is your first mistake
  By being humble, you will eventually achieve super genius status =), and even if you don't, who cares! your code is stupid simple, so you don't have to be a genius to work with it.
• Break down your tasks into sub tasks that you think should take no longer than 4-12 hours to code
• Break down your problems into many small problems. Each problem should be able to be solved within one or a very few classes
• Keep your methods small, each method should never be more than 30-40 lines. Each method should only solve one little problem, not many uses cases
  If you have a lot of conditions in your method, break these out into smaller methods.
  Not only will this be easier to read and maintain, but you will find bugs a lot faster.
  You will learn to love Right Click+Refactor in your editor.
• Keep your classes small, same methodology applies here as we described for methods.
• Solve the problem, then code it. Not the other way around
  Many developers solve their problem while they are coding, and there is nothing wrong doing that. As a matter of fact, you can do that and still adhere to the above statement.
  If you have the ability to mentally break down things into very small pieces, then by all means, do that while you are coding. But don't be afraid of refactor your code over and over and over and over again. Its the end result that counts, and number of lines is not a measurement, unless you measure that fewer is better of course.
• Don't be afraid to throw away code. Refactoring and recoding are two very important areas. As you come across requirements that didn't exist, or you weren't aware of when you wrote the code to begin with you might be able to solve the old and the new problems with an even better solution.
  If you had followed the advice above, the amount of code to rewrite would have been minimal, and if you hadn't followed the advice above, then the code should probably be rewritten anyway.
• And for all other scenarios, try to keep it as simple as possible, this is the hardest behavior pattern to apply to, but once you have it, you'll look back and will say, I can't imagine how I was doing work before.

Are there any examples of the KISS principle

There are many, and I will look for some really great one to post here. But I will leave you with the following thought:
Some of the world's greatest algorithms are always the ones with the fewest lines of code. And when we go through the lines of code, we can easily understand them. The innovator of that algorithm, broke down the problem until it was so easy to understand that he/she could implement it.
Many great problem solvers were not great coders, but yet they produced great code!

Does KISS only apply to java coding

Absolutely not, it applies to many other programming languages and extends to many other areas in your life.
The areas that the principle doesn't apply to are: emotions, love and most importantly, your marriage :)

Dynamic runtime named bind variables

public void search(String param1, String param2) {
    String sql_1 = " AND SOMETHING = :P_PARAM_1)";
    String sql_2 = " AND SOMETHING_ELSE = :P_PARAM_2";

    setWhereClause(null);
    clearWhereState();
    setWhereClause("1=1");

    if (param1 != null && param1.length() > 0) {
        addWhereClause(sql_1);
        defineNamedWhereClauseParam("P_PARAM_1", null, null);
        setNamedWhereClauseParam("P_PARAM_1", param1);
    }

    if (param2 != null && param2.length() > 0) {
        addWhereClause(sql_2);
        defineNamedWhereClauseParam("P_PARAM_2", null, null);
        setNamedWhereClauseParam("P_PARAM_2", param2);
    }

    executeQuery();
}

protected void clearWhereState() {
    ViewDefImpl viewDef = getViewDef();
    Variable[] viewInstanceVars = null;
    VariableManager viewInstanceVarMgr = ensureVariableManager();
    if (viewInstanceVarMgr != null) {
        viewInstanceVars = viewInstanceVarMgr.getVariablesOfKind(Variable.VAR_KIND_WHERE_CLAUSE_PARAM);
        if (viewInstanceVars != null) {
            for (Variable v : viewInstanceVars) {
                // only remove the variable if its not on the view def.
                if (!hasViewDefVariableNamed(v.getName())) {
                    removeNamedWhereClauseParam(v.getName());
                }
            }
        }
    }
    getDefaultRowSet().setExecuteParameters(null, null, true);
    setWhereClause(null);
    getDefaultRowSet().setWhereClauseParams(null);
}

private boolean hasViewDefVariableNamed(String name) {
    boolean ret = false;
    VariableManager viewDefVarMgr = getViewDef().ensureVariableManager();
    if (viewDefVarMgr != null) {
        try {
            ret = viewDefVarMgr.findVariable(name) != null;
        } catch (NoDefException ex) {
            // ignore
        }
    }
    return ret;
}

Why using RowSet Iterator Instead of Iterator Binding from UI?

When ever you are working with View Object Instances and your use case demands for iterating thru the rows using programmatic iteration,The recommended way for this is to create a second rowset iterator and not to use the one which is bound to the UI.

Code Snippet Illustrating the same

public void doSomething() {
    ViewObject vo = getViewObject1();
    RowSetIterator iter = vo.createRowSetIterator(null);
   
        while(iter.hasNext()) {
            Row row = iter.next();
            //your custom code
        }
    }

WHY???

Cause:

    1. The iterator bindings determine what row the end-user sees as the current row in the row set. If your own programmatic logic iterates through the row set using the same default row set iterator that the iterator binding uses, you may inadvertently change the current row the user has selected, leaving the user confused.

     2. Iterator bindings force their row set iterator to be on a valid row to guarantee that UI components display data when the row set is not empty. This has the side-effect of preventing your custom logic from navigating to the slot either before the first row or to the slot after the last row (when it is using the same row set iterator as an iterator binding). In concrete terms, this means that a typical while (rowset.hasNext()) iteration loop will either be skipped or start by processing the second row instead of the first

Passing Values to ViewObject Binding Parameters

Using Named Bind Parameters with ViewObjects

In order to avoid any SQL injection attacks , named bind variables or positional parameters approach is recommended wherever you set ViewObject where clause.

Here is the code snippet for the bind parameter approach:

public void addWhereClauseWithNamedBindParams(){
        ViewObject vo=this.getEmployee();
     
        vo.setWhereClause(null);
      
        vo.setWhereClause("Empno=:eNo");
        vo.defineNamedWhereClauseParam("eNo",new Integer("123"),null);
        vo.executeQuery();
      
        vo.removeNamedWhereClauseParam("eNo");
        vo.setWhereClause(null);
    }


Using Positional Parameters

Here is the code snippet for positional parameters approach:

public void addWhereClause(){
        ViewObject vo=this.getEmployee();
      
        vo.setWhereClauseParams(null);
        vo.setWhereClause(null);
      
        vo.setWhereClause("Eno=:1");

        vo.setWhereClauseParams(new Object[]{new Integer("123")});
      
        vo.executeQuery();
      
        vo.setWhereClauseParams(null);
        vo.setWhereClause(null);
    }

Mac: Kill Dashboard

Many users have abandoned OS X’s dashboard functionality either completely or in favor of alternatives like GeekTool. If you never want to see your dashboard again, you can kill it completely with the following Terminal command.

defaults write com.apple.dashboard mcx-disabled -boolean YES

To bring it back, change the “YES” to “NO”.