Software Acronyms/Initialisms

The below are a bunch of common acronyms you might encounter in the software industry. The below definitions are not technically correct but are correct-ish.


Test driven development. First write the tests then write the code.

This saved my ass early in my career. I needed to take a C library that converted map coordinates according to a bunch of arcane rules and produce a Java equivalent. An EXACT equivalent.

First I wrote a C program that exercised the library by passing in a whole bunch of different inputs and recorded the outputs. Then I wrote a Java equivalent of that test program. Those tests all failed of course. But once they all passed I knew I was done.


Each letter stands for a design principle.

S – Single responsibility

Each class should only have a single job. Don’t shovel a bunch of vaguely related functionality into a single class. If you ever see a class called WidgetManager or WidgetUtils that is a red flag.

O – Open Close Principle

Open for extension, closed for modification.

You should be able to extend a class without having to modify it. If you have a class called Child which inherits from Parent you should be able to add AnotherChild without modifying the existing classes.

If you add a new child class a bunch of stuff needs updating you’ve probably gone wrong somewhere.

Liskov Substitution Principle

If you have Child inheriting from Parent then you should be able to replace instances of Parent with instances of the Child without adverse effects.

Be wary of having a child class override methods inherited from the parent and making them do substantially different things. Also, child classes can tighten data validity requirements but don’t loosen them.

Interface Segregation Principle

Multiple small interfaces are better than one big one.

If a class is implementing an interface and is required to implement a method that you don’t actually care about (is the function body empty?) then something is amiss.

Dependency Inversion Principle

Depend on abstractions. Don’t pass around a PostgresConnection instance. Pass around a Database connection so you won’t have to make a million changes if you add MySql support.


Don’t repeat yourself. Don’t have the same knowledge in multiple places. Business rules will change over time. If you change instance A but don’t notice instance B you are going to have a bad time.


Model View Controller

Controllers accept input and manipulate models. Views display models. A model contains data.