Packaging Software is not about Packaging

It was a clear sky afternoon while flight 232 was heading out towards Chicago. One hour into the flight their tail engine (the plane was a DC 10) disintegrated and ruptured all the hydraulics circuits of the aircraft. Very soon the pilots realized they lost all of their flight control systems. 

This accident was later nicknamed the impossible landing, but somehow the experienced pilots did the impossible and saved two-thirds of the passengers on board.

But let’s get back to our software packaging talk and then you can continue googling about the crash. Some of you might know that planes are a passion of mine and every now and then I like to use aviation as an inspiration for my talks.

Compared to commercial pilots, packaging and deploying software does not come with such a big responsibility on our shoulders, but this does not mean we should blindly rely only on the tools to get the job done, without actually understanding how they work.

If the pilots of flight 232 would have relied only on their autopilot and the classic pilot training they would have never made it to the airport. If you choose not to understand how an application gets installed, you will let a tool eat away your next promotion or bonus.

Packaging and deployment are not just about configuring an MSI or using some silent switches. These are just the final steps of an app’s journey. 

To successfully package and deploy an application you need to first understand how it works. Why do you need to package it in the first place? And just as we do with airplanes, build a package that is designed to “prevent crashes” and has a reasonable maintenance cost.

The best part about software packaging is that it allows you to interact with multiple technologies, depending on the application you need to deploy. In some cases, not even all the developers working on that application understand what it takes to run the application because they might work only on an isolated part. 

Packaging Software is not about packaging. It is about understanding how the operating system works and how the applications interact with it. It is about database management. Inter-app communication and many more.

Only when you understand how an application works will you be able to leverage the real power of your toolset. Just like the pilots of flight 232 did when they managed to land the plane by only controlling its engine throttles.