Keep your software packages small
It wasn’t until 2004 that I got broadband internet at home. So I remember the times when downloading a new JDK (which was around 20 MB at the time) over my 56K modem line meant blocking my family’s phone line for 2 hours. Today, bandwidth doesn’t seem like a limiting factor anymore. But that doesn’t mean that download sizes for applications don’t matter – they still do.
Today, it’s not uncommon to see even relatively simple tools exceed 100 MB in size. Often, the bloat is caused by apps being based on Electron, which means they have to bundle an entire Chromium runtime.
As an example, consider pgAdmin, a GUI tool to manage PostgreSQL databases. pgAdmin 3 used to be a small, ugly-looking yet functional wxWindows-based application and required a 12 MB download. With pgAdmin 4, the team decided to do a complete rewrite of pgAdmin and used Python, Javascript, and jQuery instead. The download size immediately ballooned to 100 MB and has since grown to 140 MB – over ten times that of pgAdmin 3.
Even at 16 Mbit (which seems like a reasonable average speed for home internet), downloading a 140 MB app takes over a minute. For some reason, we assume that that’s perfectly acceptable.
The hardest part of getting a user to use your software is convincing them to download it. Once they made that decision, all you need to do is make sure that they don’t change their mind by exposing them to unnecessary friction. That’s not unlike online shopping, where the hardest part is getting a customer to the checkout process – once they’ve reached that point, all you have to do is not screw up.
Now imagine an online store that took over a minute to load the checkout page. The customer wants to pay, but all they see is a page that loads at what seems like glacial speed. That’s exactly the situation we put users into when requesting them to download an unnecessarily large software package – we disrupt their workflow, expose them to unnecessary friction, and substantially increase the chances of them losing interest.
What’s an appropriate download size and time for an app? That almost certainly depends on how high the user’s expectations are. The higher the expected value, the longer a user is probably willing to wait. For a new AAA game, users might be willing to invest an hour – but for a utility like pgAdmin, I think anything above 10 seconds is inappropriate.
It’s for that reason that having the .NET Framework be part of Windows is still valuable: It lets applications take a dependency on .NET (albeit not the latest and greatest version) without incurring additional overhead or friction – that’s a win for the developer and the user.
If you don’t hate your users, keep your software packages small and make sure they’re fast to download.