Read on Twitter
This is an excellent talk that every software engineer *and manager* should watch. I'm also going in a bit of a rant here, so 
follows. https://twitter.com/erikpistelli/status/1273245514599936001
follows. https://twitter.com/erikpistelli/status/1273245514599936001
There are many reasons why this happens. The fact software moved from being an art on itself to just being something that has to be barely good enough to sustain a business. Or many engineers having their main focus on personal gain vs the thrill and love for the art.
But one extremely frustrating problem I've seen throughout my career is people not able to identify a problem, and jumping on a "solution" that doesn't solve the original problem, and adds a lot more. As Jonathan points out, containers are a great example of this.
My second computer was a Mac Plus (first was a ZX Spectrum). I grew up with classic MacOS as being my reference to what computers should and could be, and in fact were. One aspect I assume as natural was software packaging. On MacOS, an application was a file.
For example, this was @HyperCard. A full application development environment and runtime. This was not thousands of files spread around the file system. This was not even a bundle hidden by the UI layer. This. Was. A. File. A single file. On your Mac.
(For those who don't know, the Mac file system had this amazing thing called resource forks, which allowed structured storage inside a file in a standard format, providing APIs and editors like ResEdit.).
How would you install it? You could use the original disks, that had it and a lot of other goodies, like programs (called stacks) you could run and modify freely. Or, you could simply copy it from machine to machine (using floppy disks, network, whatever).
Heck, THIS was the operating system. A folder. The entire OS was in here. You could move this to another Mac and boot from it. You could have several systems in the same disk and easily switch between each one. Imagine that with today's systems.
In my mind, there was no reason for a program to be made out of hundreds of files and directories around the file system. It was already proven that wasn't needed. Yet, that is normal today. Any kind of server software leaves a trail in many different directories.
Also, configuration was simple, it was usually just a single file inside the "Preferences" folder inside the "System Folder". You wanted to copy the configuration from one Mac to the other? Just copy the preferences file. Done.
(Side note, you can't even do that today on macOS because of the whole user defaults daemon/cache thingy that forces you to use a convoluted command line as the only way to reliably edit user defaults, as the old "delete the preferences file" doesn't really work any more)
So, today, we don't have a reliable way to move software and configurations from machine to machine and make sure they work. Something we had in the past. Introducing containers!
And here's where we fail: instead of identifying the problem, and saying “copying software should be simple”, we add a whole new insane level of complexity. Now we have two problems: our software is still complex and poorly architected, and containers are hell.
We consistently refuse to go back and redo things in a better way, based on past experience and knowledge, very often because that knowledge is lost of dismissed. We insist on walking the wrong path, and we double down on it.
