Channels ▼


Installation: Where Software Remains in the Dark Ages

As a reviewer of software products, I am disproportionately exposed to the installation process. I install lots of products. Alas, it is poor practice in a review to complain about installation, because it's a factor that the end user will generally perform once or twice. And so whether it's hard or easy will likely have little effect on the purchasing decision. So, readers don't want to hear about how hard I worked to get the software up and running. They do want to hear about problems encountered after installation, not before.

Because installation falls in a no-man's-land, where doing it poorly is rarely a cost and doing it well is rarely perceived as a gain, most software packages do it poorly. The list of poor practices is so long, that I can't do it justice in a single editorial. But it's long past time that companies started covering even the basic issues:

  • Every change to the system performed by the installation should be reversible by the uninstall script. This is particularly true on Windows systems, where products have no qualms about associating file extensions with their software, littering the register with their keys, adding unexplained directories in various parts of the user's home space, and leaving behind this detritus after the software is uninstalled.
  • Environment variables should be set sparingly, with the needs of the user in mind, and they should removed by the uninstallation process. The offense most commonly seen is the change to the execution path. Many products still prepend their favored directory to the head of the path, rather than putting it at the end. This approach runs a high risk of causing unintended problems in the event that a vendor's binaries collide with the name of some other utility on the system. If the vendor is lucky enough not to use binaries with names that create a conflict, then they should be just as happy being at the end of the execution path, so as to minimally affect the user's system.

Now let's look at an area that is often neglected: installation wizards. These supposedly user-friendly little apps are generally designed by experts in the software who cannot view the wizard's contents through the eyes of a first-time user's eyes. Frequently, features will be described by their internal name and given that many wizards have no meaningful help systems (actually, many have no help option at all), they force users to consult PDFs on other media. For example, a checkbox with the words "Install CJK fonts" is the kind of thing I have in mind. As "CJK" stands for nothing more obscure than "Chinese, Japanese, Korean," why not use the non-jargon name so that a user can know right away what to do. (It might be argued that users in those Asian countries would know what CJK fonts are, but that's no help to users who don't live there and still have to decide what to do.)

The place at which installation dialogs become truly ridiculous, however, is the approval of the license. The text box is invariably tiny and the experience of reading the undersized print so maddening that you cannot but feel that what the vendor is really communicating is: "Don't read, just approve." Nowhere have I ever seen a license consisting of a summary of the entire license with a link to the full text should the reader care to look at it in detail. Yet, there'd be no harm in such a friendly approach.

Timing is another problem that occurs, particularly with the installation of updates: The delayed information that the installation requires rebooting the system. This lack of important communication is more of the notion that "my vendor stuff is more important than the stuff you're already doing." In the case of new product installs, the delay is more likely the result of the vendor's concern that the knowledge of the need to reboot will lead the user to delay installation. But the right solution can hardly be to induce the user through ignorance, and then spring this option whose need was known all along.

And after booting, has the installation started running a new service in the background? If so, this should always be explained to the user during the initial installation so that intelligent choices can be made. The condescending view that users cannot be expected to understand the implications of running a service in the background comes from years of explaining nothing at all. Many wizards today have the option for a custom installation, which self-identifies users who are likely to be advanced and to whom such concepts can be presented and explained.

Given the long tradition of hostility to the user needs, it's tempting to think that you just have to live with what you get. But market forces actually do occasionally take installation difficulty into account. Consider, for example, the success of the CI server, Hudson. When Hudson first came out, it was one of numerous competitors in the low-to-mid-range CI server realm. It faced entrenched competition in products such as Cruise Control — an excellent, widely respected, open-source CI server. Within two years, though, the field had consolidated around Hudson for one primary reason: It was drop dead simple to install and get running. It ran as a JAR file. So installation meant copying to a directory of your choice and running the JAR file. When Hudson opened, you pointed it at an Ant file and answered a few questions about which directories to use. After that, Hudson was ready to run CI jobs without further configuration.

Few packages have so deeply understood the need for simplicity and been so richly rewarded for it as Hudson. We're starting to see a bit of a return to simple, non-disruptive installation in mobile apps, which seem to avoid many of the problems I discuss above. But they achieve simplicity in large part because they generally perform one task only. If they recall Hudson's success as their complexity (inevitably) grows, we'll be in good shape. Now, all we need is to get desktop and, especially, server apps to get on the same bandwagon.

— Andrew Binstock
Editor in Chief
Twitter: platypusguy

Related Reading

More Insights

Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.



and here we are, back to the very, first, the initial reply, which you ignore. It's a solved problem with package managers. The rare problems Linux users have exist outside of the supported package managers. That's why they were invented.


I think mthomas202 is referring to package systems, such as apt and yum. They are significantly simpler than even the best-designed Windows installer. On the other hand, installers for non-repo Linux software are pretty ghastly, there's no arguing that. The best I've seen, by far, is that for DropBox's Linux client. It's an example of what standalone Linux installers could be, but it's certainly entirely home-grown.


I don't agree. Linux is better than it used to be, but it definitely still has issues. Starting with the unfriendly access authorization, the tendency to bury pieces of apps in a variety of different filesystems, reliance on hand-editing of configuration files or scripts, etc.. Add the lack of useful help and that the path of least resistance is to push users to the command line for any non-mainline options, and you've got an equally unfriendly mess that Windows has. The one area where Linux is slightly better is the cleanup on uninstalls.


I'm not sure it's the quality of the developers. I think it's more a factor that, as I touched on briefly in the editorial, most vendors won't lose a sale because of a difficult installation process. So, there is no perceived value in putting in effort perfecting that aspect.


Agreed. Mac OS, Linux, and most smartphones all moved to better ways to do software installation and updates years ago. Windows is the outlier.


I think this argument is Windows-centric. There have been incredible advances in software installation in the Linux world. On my Ubuntu system, a software install works as seamlessly as mobile apps: Installing is a button press; I'm notified when they are updated, and can update with another click of a button. At any time I can find out exactly what files were installed and where they are. The packaging process is well-documented and dependency handling is very good.


The ability or necessity to "change the system" is a scary thing.


Another one of my pet peeves are updates that all think they need to occur at the same time. This gets ridiculous when I have not turned a computer on for a week or two and every self-important program thinks it must update immediately.


A few points:

The design of Windows makes things much more complicated and error-prone than you would think. Dealing with Windows access rights in particular is a nightmare. But it goes well beyond that.

With the move towards Internet software downloads, developers are being forced into simplifying their application install images.

Unfortunately, on most software development teams the weakest programmer is the one assigned to the installer/uninstaller. If you tried to assign a better programmer to the task then he would quit and get a job somewhere else where he could do "real" programming.


One other beef I have with installations is the use of the word "Advanced" for the setup type that lets you choose what you want. You don't need to be an advanced user to decide you don't want another browser toolbar. It (purposefully?) scares a lot of people away. I tell everyone I know, of all computer skill levels, to ALWAYS select the "Advanced" setup. Leave an option if you're not sure about it, but at least you won't get stung by something you know you don't want or need.


You only have to look at the complexity of MSI to realize "that kind of protocol is really hard to get right". Having said which, if vendors tried harder to create vanilla MSI installers, which don't have lots of custom actions, then removing those apps would have fewer side effects.


You argue that "Every change to the system performed by the installation should be reversible by the uninstall script." Of course you're right.

However, this principle has an implication that I think is far from obvious at first glance: It implies that the installation process has to be extremely careful about changing anything that any other installed program might conceivably change.

Here's why. You install program A, which adds something to the system. Now you install program B, which changes the thing that A added. Finally, you uninstall A. Does A put things back the way they were before you installed it? If so, it breaks B. Does it detect that B has changed something and leave it alone? Then uninstalling B doesn't put the system back the way it was before you started the process.

This thought experiment suggests that programs that change system state must store the previous state in places that subsequently installed programs can change if need be--and that kind of protocol is really hard to get right.