21
Demystifying Software Acronyms
I'm not sure why but we software developers do sure like our acronyms.
There are some funny ones such as:
- RTFM - Read the "freaking manual"
- PICNIC — Problem in Chair, Not in Computer
- PEBCAK — Problem Exists Between Chair and Keyboard
But as much as I would love to write an article on funny acronyms, I think it would be more appropriate to first cover the most common and useful acronyms used in software development.
Let's start of simple.
I'm sure many of us have heard of DRY and rightly so because it describes a core programming fundamental: Don't repeat yourself.
We all had this problem where we are just too lazy to export a function or a class, and simply duplicate the piece of code. This may seem easier but later on, makes your code hard to maintain. So the next time your thinking of duplicating your code, think of the DRY principle.
I like this one, because I'm the type of person who tends to overthink my solutions. Sometimes simple is best, and this is perfectly described in the KISS principle which stands for: "keep it simple stupid". So the next time your thinking of this grand scheme of code that your gonna write, try to KISS.
Through experience, you know that features are always being added and removed. In response to that you always try to add features just in case, or over-complicate your solution for the sake of extensibility. I'm not saying it's wrong to do that, but sometime you gotta follow the YAGNI principle which means: "You ain't gonna need it".
This one is comprised of five other principles:
- S - Single Responsibility Principle
- O - Open Closed Principle
- L - Liskov Substitution Principle
- I - Interface Separation Principle
- D - Dependency Inversion Principle
In a nutshell, they are the SOLID principles designed to make software design understandable, flexible and maintainable. If you want to learn more I have an article on each principle, you can check it out here.
You wouldn't write your whole program in one file right?
I sure do hope not.
We should separate classes based on their features or other metric your using.
This is the basic premise of separation of concern, or in short SOC.
This is taken a step further in service oriented architecture, where you have a separate program for each feature or domain.
Before the days of AGILE, we had BDUF or Big Design Up Front.
BDUF is basically an approach to software development where the software design is perfected up front before the implemention. So before you would begin writing a program, you would first design it, with as much detail as possible and only then would you begin writing code.
MVP stands for "Minimum Viable Product". It's basically a very early version of a product where it can be used by first customers who then can give back feedback for future product development.
PoC stands for "proof of concept", it basically helps you determine if you idea is a feasible product. Unlike MVP, PoC isn't a fully fledged product, it most probably has only one feature that is given to certain testers to see if it's sensible to continue development.
This was a fun article to write, and I hope an educational one too. As always if you got any questions feel free to leave them down in the comments below.
Thanks for reading!
21