Reproducibility. Much of humanity’s problems with software comes down to reproducibility.
For example, let’s say a customer of yours encounters a bug when using your software. In order to fix the bug you’ll need to identify how to reproduce it so you can verify that a fix you come up with makes the bug no longer reproducible. That is inherently what solving a bug means!
The ideal software development environment strives for “dev-prod parity”—short for “development-production parity.” 1
If your production environment behaves differently than your development environment, then how do you know the code that works on your laptop will work in production? By eliminating room for deviations between your environments you reduce cases of “it-worked-on-my-laptop.”
Another illustrative example of this problem of reproducibility in software is that your coworkers (or contractors) who are trying to contribute to your software might have to follow a 6-page document about how to setup their laptop on their first day on the job! What if your contractor has a Windows laptop and you have a Mac laptop? Good GRIEF! Isn’t software supposed to automate this process??
Docker is one solution to both these scenarios (bug-fixing, local development). It eliminates deviations between your development and production environments because it offers a standard for how to package together an operating system + 3rd party dependencies + your own source code—that can be ran from any Docker-supported operating system. 2