09 July 2012


Today I bring you yet another set of acronyms that the software development community has invented in order to fully confuse anyone desperately trying to put order in this art.

So what is KISS?

My personal favourite principle, acronym for "Keep it simple, stupid!". In case it sounds to politically incorrect for some public presentation you could try and change it to "Keep it simple and stupid", but still this is probably the number one mistake developers tend do do. It is also applicable for almost any system that is being developed - that being a software, hardware or whatever system.
The main idea here is just that - the more complicate a solution to a problem is, the bigger the chance for it to be unsuccessful. A typical sign of overengineering is adding too many layers of complexity for solving a simple problem.
A good software engineer should always consider if the effort put into solving some problem is not an overkill, typically in the prototyping and planning cycle, but also in the development cycle when implementing the initially planed software skeleton. This principle is very tightly connected with the YAGNI principle.

So what is DRY?

Yeees it is a bad idea to "just copy this code from the other class". This principle stand behind the idea that you do not repeat yourself. Copying your code has many disadvantages - you need to maintain both pieces of code, if one changes and the other does not you introduce possible instability. And after all OOP languages give you many ways to avoid code repetition.
For me personally having duplicate code is always bad design and never a good idea. Of course there are other areas one should avoid repeating himself - tests, DB schemas, etc, but code repetition is the most common instance.

So what is YAGNI?

Another perspective of the KISS principle is "You ain't gonna need it". This is a very valid point for people like me who like the ideas behind extreme programming.
Generally the principle argues that one should not write any code that is not immediately required for solving one problem. aside from avoiding overengineering it also help keep the code base simple. You could be 100% sure that some feature would be required, but unless you are working on it you need only to make sure you do not make your code such that it would require much refactoring to include this feature. coding the feature as part of another feature or because you believe it would benefit the whole project is genuinely wrong - not only does it slow you down but it removes the focus of your work. Do not write code you are not going to use!