11 technology acronyms software developers need to know
If you’re a junior developer on your first project, you’ll likely encounter a variety of technology acronyms, italicizations and abbreviations you’ve never heard before.
Is the confusing term you just heard, something everyone’s expected to know? That can be an intimidating situation. Moreover, it can be embarrassing for a junior dev to ask for clarification on what a software abbreviation or technical acronym means.
Software technology acronyms
To help alleviate some embarrassment on your first software development project, here are explanations of the meaning of several technical acronyms:
KISS: Keep it simple, stupid
This technology acronym actually means: Keep it simple, stupid.
Don’t worry, the term is (almost always) said in jest. Despite the use of the word stupid, this programming acronym is not intended as an insult.
Inexperienced developers often overdesign a system and deliver an increment of work that is far more complicated than it needs to be. In such cases, it would be better for them to use the KISS method, and keep it simple.
YAGNI: You ain’t gonna need it
It’s difficult for a developer to write code and not envision multiple, optional, ways to reuse that code in the future.
This can lead the developer to add methods, functions and constructors that aren’t required today, but possibly needed in the future.
That’s a bad practice. Don’t write methods or functions you think you might need someday. This is a waste of time, because more often than not you ain’t gonna need it (YAGNI).
TAGRI: They ain’t gonna read it
When the manager asks you to work some overtime to write some in-depth documentation, you can hit them with this technical acronym.
The production of superfluous documentation for users can be a genuine waste of time, because the reality is they ain’t gonna read it (TAGRI).
DRY: Don’t repeat yourself
Don’t copy and paste code, and don’t create a bunch of functions that do essentially the same thing.
Write code that is concise, reusable, modular and abstract enough that it can be called in multiple places throughout your program.
Keep your code DRY. Don’t repeat yourself.
WET: Write everything twice
Abstraction is often used to implement the DRY principle.
Unfortunately, poorly implemented abstractions added early into the codebase can cause serious headaches when changes must be made in the future.
Some software architects like to be WET before they are DRY. In other words, encourage developers to write everything twice until the codebase is established, and the benefit of using abstractions is completely clear.
SOLID: Object-oriented software best practices
The SOLID acronym refers to the following five, object-oriented software development principles and best practices:
- Liskov substitution;
- Interface segregation; and
- Dependency inversion.
Enforce these principles, and your applications will be more reliable and more easily maintained.
ORM: Object relational mapping
It can be difficult to map object-oriented code in a Java program to tables and records in a database.
To alleviate the object-relational impedance mismatch, many database driven applications rely on object relational mapping and use an ORM tool such as Hibernate, JPA or Toplink to bridge the gap.
OBOE: Off by one error
Also known as a fencepost error, an off-by-one-error (OBOE) occurs when conditional logic within a loop uses a less-than operator, or < , rather than a less-than-and-equal-to operator, or ≤.
This causes a loop to either exit one iteration too early, or leave one iteration too soon — thus, the reference to the off-by-one-error.
POC: Proof of concept
A proof of concept (POC) provides a working piece of software that proves an idea or a vision is feasible.
A POC only needs to implement happy-path programming, which essentially means tightly controlled code intended to achieve desired functionality with no errors. There is no need for a polished UI. At this stage, the app won’t be launched at customers.
A POC is just used internally to prove that a given idea or product is doable.
MVP: Minimal viable product
In sports, an MVP is the most valuable player for a team or league.
In software development, however, MVP is the minimal viable product you can deliver to customers in an initial release. It provides only the core features an application needs to satisfy user requirements. It also must be bug-free and look polished.
An MVP release has a much higher quality and functionality standard than a POC.
POS: Point of sale
You’ve likely run into this acronym outside of the technical world.
It has a different meaning for software developers employed in the retail industry.
Point of sale machines are essentially cash registers, although the term can apply to any cell phone, mobile or embedded device that can handle product payments.
Acronyms, italicizations and abbreviations
Hopefully this list of 11 technology acronyms commonly heard around software development projects will help you better understand the conversations you have with developers and product owners in your daily scrums and standup meetings.