The Engineering Acronyms We Swear By
Engineering is a complex and ever-evolving field that requires clear and concise communication in order to be successful. One of the ways engineers are able to improve this communication is with acronyms. Whether you’re a seasoned engineer with years of experience or just starting out in the field, it’s important to familiarize yourself with the most common and useful engineering acronyms. Tried and tested, we outline our favorite engineering acronyms, including:
- DRY
- SOLID
- YAGNI
- KISS
DRY
“Don’t repeat yourself” is a principle of software development aimed at reducing repetition of software patterns, replacing it with abstractions or using data normalization to avoid redundancy:
“Every piece of knowledge must have a single, unambiguous, authoritative representation within a system”.
The principle was formulated by Andy Hunt and Dave Thomas in their book The Pragmatic Programmer. When the DRY principle is applied successfully, a modification of any single element of a system does not require a change in other logically unrelated elements.
Common examples of DRY include sending emails, using database connection pools and other instances where code can be written once and reused in the application a number of times. While it may seem to be a technique to decrease the code base, the main purpose of this principle is to discourage copy-paste programming and make our code more maintainable by having only a single instance of reusable code in the application.
A common misinterpretation of DRY is the need to make all classes overly generic or make them accommodate any functionality (breaking the SOLID principle, below). A common side effect of misusing this practice is to have “Swiss Army Knife” components which, in order to be reusable in different (most of the time unforeseen – see YAGNI) situations begin to encapsulate multiple actions, breaking the Single Responsibility Principle (also below).
Both back-end and front-end software benefits from having reusable code or components since it greatly reduces the development time by avoiding re-writing and testing the same thing multiple times. Conceptually, this is a great way to ensure the DRY principle and we encourage/expect it at Mercury.
SOLID
In software engineering, SOLID is a mnemonic acronym for five design principles intended to make software designs more understandable, flexible, and maintainable. The SOLID ideas are:
- Single-responsibility principle: “There should never be more than one reason for a class to change.” In other words, every class should have only one responsibility.
- Open–closed principle: “Software entities … should be open for extension but closed for modification.”
- Liskov substitution principle: “Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it.”
- Interface segregation principle: “Many client-specific interfaces are better than one general-purpose interface.”
- Dependency inversion principle: “Depend upon abstractions, [not] concretions.”
YAGNI
YAGNI is an acronym that stands for “You Ain’t Gonna Need It”. It is a mantra you will frequently hear from members of Agile software teams and hopefully from time to time within Mercury. It’s a statement that some capability we presume our software needs in the future should not be built now because we just aren’t gonna need it.
Like many elements of Agile and Extreme Programming, it’s a sharp contrast (and frankly, a reaction) to elements of the widely held principles of software engineering in the late 90s. At that (pre-Agile) time there was a big push for careful up-front planning of software development whereas modern approaches espoused at Mercury embrace incremental value (and thus software) creation.
The common reason why engineers build presumptive features is because they think it will be cheaper to build it now rather than build it later. If you combine the probability of that feature actually being needed with the hoped-for ease of flexible project management (via a sage Product Manager) and more flexible software architectures, the much greater probability is that at best the cost of implementing it “up front” is not actually much lower than doing it when it is proven to be needed.
KISS
An acronym for Keep It Simple, Stupid, is a design principle noted by the U.S. Navy in 1960. The KISS principle states that most systems work best if they are kept simple rather than made complicated; therefore, simplicity should be a key goal in design, and unnecessary complexity should be avoided.
Conclusion
Engineering acronyms can be powerful tools for streamlining communication and increasing efficiency within the field. Whether you are a seasoned engineer or just starting out, it is important to familiarize yourself with the most common and useful best practices, which are often accompanied by clever acronyms. By becoming familiar with these tried-and-true engineering acronyms, you’ll improve your understanding of technical concepts and better navigate the complex world of engineering.
Are there design principle acronyms we may have missed? Tell us by tagging us on LinkedIn. We’d love to hear from you!