Do the simplest thing that could possibly work

From CSSEMediaWiki
(Difference between revisions)
Jump to: navigation, search
(See Also)
m (Reverted edits by Ebybymic (Talk); changed back to last version by Aidan Bebbington)
 
(5 intermediate revisions by 4 users not shown)
Line 11: Line 11:
 
In some applications, additional requirements such as security are important. In these cases, you should still do the simplest thing that will satisfy the requirements, and not take it as an excuse to write overly complex code.
 
In some applications, additional requirements such as security are important. In these cases, you should still do the simplest thing that will satisfy the requirements, and not take it as an excuse to write overly complex code.
  
An important aspect of this is not to spend too much time adding additional functionality that you might need later. When writing software, one should get all the bare essentials done first, before adding extra, possible unnecessary functionality.
+
An important aspect of this is not to spend too much time adding additional functionality that you might need later. When writing software, one should get all the bare essentials done first, before adding extra, possibly unnecessary functionality.
 +
 
 +
This is also known as "[[Keep it simple]]" and "Keep it simple, stupid" (KISS).
 +
 
 +
==Conflicts==
 +
* [[Big design up front]]
  
 
==See Also==
 
==See Also==
 
* [[Premature optimization]]
 
* [[Premature optimization]]
* [[You Ain't Gonna Need It]]
+
* [[You ain't gonna need it]]
 
* [[Don't repeat yourself]]
 
* [[Don't repeat yourself]]

Latest revision as of 03:23, 25 November 2010

This is a fairly self-explanatory design maxim. In general, the simplest solution is the best solution. Simple solutions have the following benefits:

  • They will probably have less bugs. Generally, bugs are introduced when the code is complex; nice simple code should be relatively bug free.
  • They are easier to maintain. Future programmers (including yourself) will be able to understand your code quickly, making maintenance easier.
  • They are quicker to write. Writing simple, easy bits of code means you can spend more time on complex code, and gets the easy bits out of the way.
  • They will probably be faster. Often, simple code runs faster than complex code. (Obviously in some cases this will not be true).
  • They are more elegant. A good programmer will make a hard task look easy; a bad programmer will make an easy task look hard.

It should be easy to see why its always a good idea to keep it simple. If you are worried about efficiency, and think a more complex solution would be faster, do it the easy way first, then if needed optimise later.

In some applications, additional requirements such as security are important. In these cases, you should still do the simplest thing that will satisfy the requirements, and not take it as an excuse to write overly complex code.

An important aspect of this is not to spend too much time adding additional functionality that you might need later. When writing software, one should get all the bare essentials done first, before adding extra, possibly unnecessary functionality.

This is also known as "Keep it simple" and "Keep it simple, stupid" (KISS).

Conflicts

See Also

Personal tools