I’ve never understood why software installers are so large. If you can package 100,000 lines of code into 4 Mb, why does any program I’m downloading need 50 Mb?
When we started developing AetherStore, I wanted to ensure that our installer didn’t turn out this way. But, after one year of development, our latest release is 50 Mb… and I’m okay with that. Here’s why:
Don’t Repeat Yourself
A good programmer has the ‘DRY’ mantra firmly engrained in their head — re-writing an algorithm that someone has already written and tested is a waste of time and an easy source of error. But it’s easy to take this too far when you start out on a project.
For example, if you’ve got a collections problem, Google Guava probably has a solution, but it adds 2.5 Mb.
Similarly, there are numerous Apache projects that look small at first glance, but actually require a whole other set of dependencies to run correctly. Once you’ve added the commons-io, commons-logging, mail, and activation JARs, you’ve used a few more megabytes in space.
So before you’ve even started writing your own code, you can end up with a 5 Mb release. We attempted to avoid this pitfall by not using any external libraries unless they were absolutely necessary. With roughly 35,000 lines of our own code, we had a compact release.
Current size: Code: 2.5 Mb Total: 2.5 Mb
As development continued, we started adding graphics and other assets that increased the size of the project. For some programs, graphics take up a significant chunk of space, but because AetherStore relies on the existing Windows Explorer interface, the space needed for these assets is relatively small.
Current size: Code: 2.5 Mb Graphics: 600 Kb Total: 3.1 Mb
To create our first piece full AetherStore release, we bundled this code and graphics into an installer, along with a handful of JARs and the native libraries needed for file system integration:
Code: 2.5 Mb
Graphics: 600 Kb
Packaged Libraries: 1.8 Mb
Native Libraries: 2 Mb
Installer overhead: 600 Kb
Total size: 7.2 Mb
This is where I’d like our story to have ended, but sadly it doesn’t. While the installer works perfectly, the user experience can be terrible. If a user doesn’t have Java installed on their machine (a pre-requisite), the installer provides a link to the Oracle download site. This takes a relatively short and simple installation process and adds a few extra steps that require the user to navigate an entirely separate installation process. Moreover, requiring a hidden 41 Mb download (Java SE 7u21, Windows x64) doesn’t make our program any more compact.
The alternative is to abandon our aim of providing a small download and bundle Java with the AetherStore installer. This balloons the size of our installer, but massively improves the user experience. It also means we can use the latest version of Java without worrying about compatibility on user machines.
AetherStore without bundling: 7.2 Mb
AetherStore with bundling: 51.2 Mb
How Important is Size?
All of this leads to a simple question. In a trade-off between size and simplicity, how much do we care about size?
I’m just about old enough to remember when a 5 Kb/s down link was cause for mass celebration, and a 10 Mb download represented a significant commitment. But given the ubiquity of fast internet connections, should the size of your software even factor into any development or release decisions?
I’m increasingly, and somewhat reluctantly, starting to think that it shouldn’t The cost of having an extra few megabytes is insignificant compared to the additional cognitive complexity of an extra installation step, or the time required to emulate functionality already found in widely used, well tested utilities. We can still provide an un-bundled installer, but it won’t be the most common option.
Ultimately, the size of an application isn’t as important as it once was.
Latest posts by Angus Macdonald (see all)
- Creating a Java REST API with Jersey (Including Code Example) - February 27, 2014
- Effective Communication in a (Very) Small Company - February 20, 2014
- Workstation Resource Utilization Goes Local (Again) - October 17, 2013