The software design principles you should remember.

acronym: is a word formed from the initial components of a longer name or phrase

During my time as a software engineer, I have heard so many acronyms that I could not even try to guess the number in thousands. Acronyms are a bit overused in our field. There are acronyms everywhere, in every area, in some cases they help to shrink names, but in some others they are used just made up to make cool names.

Personally, I like acronyms as a tool to encapsulate much deeper knowledge in just a simple word. As a kid/teen I used to use them quite a lot to remember lists of stuff for my exams, but now as an adult and as a software engineer, more specifically, I can still use some acronyms related to software design on a daily basis. These acronyms are not to remember lists, these acronyms are to remember design principles.

• KISS: Keep it simple, stupid
  There is not much to add to clarify the intention of this principle. Avoid unnecessary complexity on your solutions, try to keep them Simple, Short, Small, Straightforward,... When software is simple, it makes it easy to understand, easy to maintain and easy to extend.

• DRY: Don’t repeat yourself
  This principle is easy to understand, but not so easy to spot in a real life project. It goes a bit further than some copy-pasted chunk of code. The theory says: “Every piece of knowledge must have a single, unambiguous, authoritative representation within a system” and what it means is that sometimes, especially in large projects, you have split logic into two or more places, because it looked completely different, but after a while it turned out that they have some logic shared between them. In order to avoid synchronous changes in all these places, put together this shared logic in a single place.

• YAGNI: You ain’t gonna need it
  The software principle behind this acronym tries to avoid all functionality in the system that is not needed or used yet. Do not bring anything that you foresee that you will need but it is not required/used now, because in the future when you need that, you will have more context and the software may have changed, so then, you can come up with a much better solution. This is commonly used when pairing doing TDD because you or your partner don’t stick to “do the simplest thing that could possibly work” or DTSTTCPW. Don’t waste resources nor compromise the possible final solution at this point.

• TDA: Tell don’t ask
  Again, easy to remember, but not so easy to identify in real life projects. This happens when you have split the logic and the data needed for that logic. The module/class/component that has the logic needs to ask for the data in order to perform the action, this generates an extra communication between elements that could be avoided. Wouldn’t it be more convenient, and if it is your case, more object-oriented if the logic was tied together with the data? An example, imagine you want to calculate the bonus of an employee, you need to ask for that employee’s name, the position, its current salary, days worked, project performance,... whatever, and then when you have all the data do the calculations, right? Wouldn’t it make more sense that the employee had (directly or indirectly) the bonus calculation logic and simply use the payBonus function instead of all the getters?

• LOD*: Law of Demeter
  The last one is not a principle, but it can be used as a guideline of design. The purpose is to limit the access boundaries of the objects. Simplifying it with an example, given an object A that accesses an object B, and this object B access an object C. You could never ever from A, use B to access C. A should only know about B and communicate with it and not mix with any of the concerns of C. This is to keep responsibilities separated which makes it is easy to extend and maintain.
  
  
  

After reviewing these acronyms, it has never been so easy to remember how to write good code, right? Now I guess we only need to remember when to do it… I use these acronyms quite often, especially when I am pairing with other people. I like them because they are easy to remember for everybody, not just me, and also because of the massive amount of knowledge compressed in just a few words. They may look silly or obvious, but they are a distilled sentences of really complex and recurrent problems in software development.