Why Should I care About Installers?

While many (notice I'm not saying all) software companies are aware of the usability, UI (User Interface) and UX (User eXperience) aspects of their software and can sometimes actually draw a direct correlation from the state of their application's usability to their customer's satisfaction level, not that many of them dedicate enough attention to the state of their installers.

The installer is the first (and last) piece of software your customer sees. They say there is no second first-impression. The experience your customer goes through while first installing your product will stay with him and dictate the general feeling he'll have towards your application.

A crappy installer will suggest to the customer that the software vendor does not pay attention to details and that "quality" is a "nice-to-have" value to their development team. A faulty or crashing installer may even suggest worse - and may cause your customer to not recommend your software, or even return it.

So, why should you care about installers?

• If you're a software user, chances are you've gone through at least one installer experience in your life, not to say hundreds. And chances are some of those installation experiences turned into horror stories, with crashes, reboots and a myriad of DLLs left behind on your hard disk.
  
  
• If you're a software vendor (in sales, marketing, PM etc.) you want to make the best first impression on your client. You want him to see the quality and attention and dedication you've put into your product. Because you want referrals and repeat business. And because if you really believe in the product you sell, you want every nut and bolt to function properly and provide a seamless great experience.
  • Install your software and use it. Don't trust anyone who says "it's great" - experience it yourself, like your customers are about to.
  • Try uninstalling it.
  • Become familiar with the language used throughout the installation process. Write down comments and locate typos early.
  • Don't accept an "it's too late to fix" excuse from your R&D team. Fixing installers is easy - fixing bad experiences and reputation is hard, if not impossible.
    
    
• If you're a software developer your work is not done when you check in that last piece of code to your SCM (Software Control Management) system, or when the last QA test passes successfully. You should care about how the end customer will experience your amazing code, if he can even get to it.
• Once a release candidate is announced, get the latest installer package and install it. In the past, the common excuse was "if I install the product on my dev machine it'll ruin all the dependencies". This excuse is dead, now that everyone has access to infinite virtual machines.
• If the environment is too complex to replicate in a single VM, hop over to the QA test lab and ask one of your colleagues to use their test rig.
• Install the software, check the full process and write down comments, use YOUR software (I find it mind boggling that there are developers who can not use their own company's product - including something they've developed themselves).
• Finally, attempt to uninstall the software. Uninstallation is an important part of a software's lifecycle and should not cause your users undue grief.

The problem is that most software companies just don't have dedicated installer developers. And yes, I do mean developers - like every other piece of your software, installers contain logic and need to be tested before being released. In most companies I worked for, the installer development is assigned to a developer who doesn't currently have 120% work load on his plate. Or to a QA guy. Or to someone on the support team. That guy/gal may not have any experience with installers/system resources/scripting or all the other skills needed to build a good installer.

Without a clear spec or test plan, he'll fail to check what happens when that installer runs on a machine that doesn't have the required framework installed; or has an earlier version of the same software; or has a necessary file locked etc. He'll probably test it on his machine, or maybe a VM with a similar OS - completely neglecting to check the myriad of versions his software is supposed to support.

He'll forget to update version numbers between versions, include old or wrong strings and fail to check for new requirements. And all of it is not his fault. It's the fault of the Development Manager who allowed this situation to happen, the Product Manager who allows his product to look like crap, and the QA manager (if there is one) for signing off on an incomplete product.

Man, I could go on an on about this and maybe share some of my experiences for the brief period i was in charge of the installer development in one of those companies. But I've decided to take a shortcut. I posted a question on LinkedIn, and got 4 good replies, each covering a different aspect of the issue and offering excuses/reasons for the current state of the industry. Enjoy.

And fix those damn installers .