Technology acronyms demystified!
Acronyms are great… when used wisely. They can be easier on the brain, some are actual mnemonics - hinting at their expansion’s meaning (see DRY, KISS as examples). That said, these advantages may be nullified by the sheer volume of acronyms one must recall in common technical parlance. If any expansions escape you, you are not alone.
The turboencabulator is a pretend machine developed in 1944, conceived to mock technobabble. Several decades later any programming paradigm argument will eventually see OOP, DRY, and SOLID in the same sentence to bamboozle opponents in very much the same spirit. Add SCRUM for good measure.
Lists of expansions abound online, but most acronyms fall in one or more of the following broad categories:
Domain Driven Design is “Driven” more vaguely, stating that system design should stem from the real-world system concerned. Doing an accounting tool? Learn accounting
Deceptively easy to state, not to do, like Keep It Simple, Stupid (define “Simple”… )
Like Yet Another Markup Language, references the “culture” in its expansion
{
‘Single responsibility’:
‘each class should be responsible for one thing’,
‘Open-closed’:
‘Entities are open to expansion, closed to modification’,
‘Liskov substitution’:
‘Using a derived class should be identical to the base class’,
‘Interface segregation’:
‘Make interfaces containing only methods you use’,
‘Dependency inversion’:
‘Depend on high level abstractions, not implementations’
}
Godspeed and HF!
(HF: Have Fun. Gamers say it, those pesky mouse-clickers)
If you find software development, design, systems thinking and management interesting - just drop your email into the box below. We write content roughly every other week, we won't share your mail with anyone, and we certainly won't spam you.
...and you're done! Thank you so much!