As we move into the age of component-oriented software, reliable installation programs are more important and harder to write than ever. An installation program is no longer a matter of copying a few files to a directory and perhaps adding a line to the end of a CONFIG.SYS or AUTOEXEC.BAT file. Many installation programs must now install several different pieces of software in a product suite. It is typical for an installation program these days to register COM components, to increment usage counts for shared .DLLs, and (shudder!) to update system software on the machine. Installation programs must also log the state of the system such that the program can be uninstalled reliably and successfully.
All this would be a complex task for an experienced, senior programmer. However, at many companies, installation programming is considered to be an entry-level job, and in some, it's a real ghetto. Installation programs are often assigned to programmers who are not members of the product team; a lack of knowledge, poor specifications, and unclear communication cause defects. The installation program is often the last item of business in the development of a piece of software, and is therefore more likely to be insufficiently planned, hastily developed, and poorly tested. Often, the installation programmer is left with all of the responsibility and none of the control.
A robust installation program is critical to the success of your product. It's the first interaction a customer has with your software. You never get a second chance to make a first impression; customers will tend to believe that a bad installation program is consistent with the software being installed. By contrast, products that have fewer defects satisfy customers, reduce the burden on technical support, and require less maintenance-and thereby save money for your company.
Defects in general are expensive, and defects associated with installation can be more pernicious than other problems. A minor problem with one feature of a product may not affect the customer, but if there is a problem with installation, the entire product stands a chance of not working at all. A customer who cannot install and run the product will often give up, exchange your product for that of a competitor, and then tell people about the bad experience. The loss to your company in this case extends far beyond the loss for the single unit.
However, even if the customer chooses to keep the product and work with technical support, the cost of support can wipe out the profit on a unit. Consider a package of commercial software sold at retail for $60. The publisher's revenue on such a product is likely to be $30 or so. Assume that the fully-burdened cost of a tech support call-not a complicated one, just one that makes the phone ring-is estimated at $10. This means that a single call to technical support will cut that unit's revenue by 33%-and that's not profit, that's revenue. While the customer is on the phone to technical support, she may have to reinstall the product. If the product is large and the installation process is complicated, the user will have to enter data and choose options, wait for all of the files to be copied, reboot the system, log in to the network, and restart the program-and all this potentially several times as the problem is resolved. Nothing productive happens either for the customer or the support representative for many minutes. This is a waste of time and money for everyone involved, and is not likely to endear your product or your company to the customer.
The installation program is critical not only to the success of the released product, but also to the beta test. An installation program that is not ready for prime time can lead to plenty of wasted time and effort for beta testers, beta coordinators, quality assurance engineers, and developers. Of the dozens of products that I have beta tested in the past, all had serious problems with installation. Although the software under test was typically defect-ridden, the accompanying installation programs were even worse. Predictably, installation problems frequently led to my being unable to test the main program at all. When installation problems weren't crippling, misconfiguration of the main program by the installer led to a number of problems; upon submitting a problem report for these, I was often informed that my defect wasn't really an issue, but "a simple installation defect." I'm reasonably certain that a customer wouldn't care about the distinction. In any case, my report was therefore spurious, and the testing, analysis, and reporting that I had done for that defect was therefore completely useless and wasted. All of these problems made me disinclined to bother testing the products at all. I was also reluctant to install the released versions of the products, even when they were provided as a "reward" for my beta testing.
Quite apart from coding defects, installation programs are often poorly designed. Software is poorly designed when it doesn't match the customer's goal. To the customer, the purpose of an installation program is to place the software on the disk, quickly and efficiently, with an absolute minimum amount of configuration required. After a couple of very quick and easy-to-understand questions, the time- consuming parts of the process should finish without any further intervention required from the user. Upon completion of the installation routine, the program should be ready to run. The goal of installation is not to bewilder the user with options; not to enforce licensing issues; and certainly not to sell more software to the customer.
As usual, planning, consideration, and preparation can prevent coding errors and design problems, and will help you to deliver an excellent installation routine. Here are a few points to consider, first about the person doing the work of coding the installation program, and later about the installation program itself.
Your installation programmer should be a charter member of the programming staff for your product, participating in planning, design, and code review from the outset, just as the rest of your programmers should be. The degree of involvement may depend somewhat upon your company's structure. In smaller companies, installation may be the responsibility of a member of your product product development team; this person may also be responsible for other components of the product. In larger companies, installation programming may be treated as a shared service, with one or more specialists writing installation programs for several products. In either case, installation programmers should be treated neither as lackeys nor as mercenaries, but as bona fide members of your product's team. The installation programmer should also be welcome to participate in other team activities, recreation, and rewards.
Reconsider the common prejudice that the installation programmer should be the most junior person on the programming team. In any case, make sure that the installation programmer receives training and mentoring at least equal to the other members of the team. Adequate mentoring may require a senior programmer to be familiar with installation issues, processes and tools. Give the senior hand time to learn the material, and give her time to counsel the less- experienced programmer in best practices. It is of excellent value to educate and promote junior programmers this way, even after you account for the cost of the expert's time. In the course of your department's evolution, installation programmers will move into more senior positions and will be able to provide mentoring on installation to the newer staff.
On a product team, consider making the installation programmer one of a pair of development staff that provides installation and configuration management services. The installation programmer needs a complete, accurate, and informed map of the product's file lists, file locations, and registry settings, and this forms an important check and balance on configuration management issues. Since configuration management (at least in the form of source control) should be available from day one, so should the installation program be started very early in the development process, as a fundamental part of the product's planning and design. If you're in a small shop, and only two developers are working on the entire project, make one responsible for configuration management and the other responsible for writing the installation program. In a larger organization, where installation programs or configuration management might be shared services, try to ensure that installation and configuration management staff work hand in hand, forming a natural quality group.
Consider the importance of the installation program to the customer: since the installation program for your product is the first piece of your software that a customer sees, it deserves to be more than an afterthought. This means that installation concerns should be on the project plan from day one, and that the installation should be carefully designed, planned, internationalized, implemented, and tested, just as the rest of your product should be. The requirements, design, and code for the installation program should be kept in source control along with the rest of the product. The source for the installation program should be written, reviewed, and tested to (at least!) the same standards of quality as the source for the main program. When the product moves into system test, testing should be based on the product as installed by the installation program.
An installation program should be applied to a design pattern. Although component software makes installation programs more challenging, installers should rarely do anything outside a set of basic tasks. An installation program should ensure that it is running on a system that fulfills the product's system requirements; should obtain the minimum amount of configuration information from the user; should place required files in appropriate places on the hard drive; and should offer to start the main program, or advise the user on how to do it later. That's all. Within these tasks, there is a set of requirements and functions common to all installation programs. Many of these can be anticipated easily, allowing requirements for an installation program to be placed into a template or questionnaire. Much of the routine work can be automated and code can be reused. If a product requires an installation script that deviates from the template, consider the need for the departure; an unusual installation request may signal a design problem in the main program.
Installation involves putting the required software onto the system and making it ready to run for the first time. Most configuration and customization can be done at any time; most options need not be set for the first run of the product. Don't make the customer feel like the guest of honor at the Inquisition; instead, relieve the customer from having to make too many choices at installation time. Don't force the user into choices before he's even seen the program; provide sensible defaults, allow the user to become familiar with the product, and provide straightforward ways to change the configuration within the main program itself. This shouldn't be difficult in the least, and in fact is better design. If you feel that a program option is so important that the issue must be decided at installation time, it's probably a poorly-considered option irrespective of when it is configured.
This may sound like heresy, but as computer professionals, many of us like to take a lot of control over the installation process when it's not truly necessary. However, we're unusual; remember that most customers are different from ourselves. If your installation program provides a simple installation process, you will satisfy your customers.
After you've done quick, basic checks to make sure that the operating platform is compatible with your product, gather from the user as little information as you will need to finish the installation process. Save the user time by obtaining default information from the previous versions of your product. After you have obtained the required information, finish the rest of the process without any more intervention from the user.
Network administrators in particular appreciate unattended installation. Allow your installation program to read settings-- including all the standard ones, such as user name and target directory--from an easily-edited text file.
From its earliest days, Windows promised to make life with the operating system more harmonious by allowing for shared libraries, which should allow programs to use a common set of up-to-date services. Alas, it seems that each program released seems to have its own idea of what common services should be, and replaces key operating system files accordingly. Microsoft has historically compounded the problem by permitting the line between operating systems, runtime libraries, and shared components to be blurred, and encouraging application vendors to provide new versions of whatever was available. After recognizing the problems that this caused, Microsoft put restrictions on redistribution of operating system files, insisting that files be installed via its own mechanisms. These routines had problems of their own, and the updates often conflicted with older software already on the machine. Do you want to participate in this derangement? These practices are reportedly intended to stop with Windows 2000, but there are surely minefields in the design of component objects that will include dangers for installation programs.
In fact it is worth asking why your program has been designed to use only the very latest operating system files or add-ons. There is a risk that the newest technologies might not be entirely stable, or might be incompatible with older systems still in the field. Operating system updates in the middle of an application's installation add further complication and risk. You'll never hear a single person express thanks for a new version of some critical system file that came with your product, but you'll surely hear about it when other applications suddenly stop working after your installation program. Rebooting the system alone is highly annoying to customers, especially if it's done unnecessarily or without warning.
Most products released these days with installation programs written with one of the installation toolkits, such as InstallShield or WISE Installer. These packages can be useful in simplifying complicated installation processes. However, if you are successful in keeping your installation requirements simple, you may not need these packages; make this a goal. Check out the services offered by the Microsoft Setup APIs; when combined with a tiny stub program, they may be sufficient for the needs of your product.
If you do use one of the installation toolkits, be aware that they are software products that have their own sets of problems and potential for conflict. Keep up to date on their defects and be prepared to code around them. Consider taking advantage of training courses offered by the toolkit company, but be prepared also to challenge the assumptions the company makes about how installations should be done. After all, most installation programs--the ones customers complain about--are prepared with these tools.
If you're used to installing software yourself, you'll be familiar with things that annoy you about installation programs; avoid those things in your own products. Above all, don't waste the user's time. Don't surprise the user with a system requirement that will halt installation after plenty of disks have been inserted and the files have been copied; do necessary checks accurately before any work is done. If an installation requires multiple disks, arrange the disk layout such that the customer never has to re-insert a disk that has been used earlier in the process.
Don't ask the user for information that might not be immediately at hand, especially when that information is irrelevant to the operation of the product. Don't make input of a user name mandatory. If your product is going to display the user's name or company information, check the Registry and offer as a default the name associated with the previous version of your program, or the user name and company gathered during Windows' installation process. Allow the user to enter or edit the name after installation. Similarly, if your product stores the customer's serial number on disk, allow the customer the option to enter the serial number later. A serial number just an identifier, despite the fact that many companies seem to mistake it for a form of copy protection. If the user is stealing the installation disk, he's just as likely to steal the serial number.
Don't put programs onto the desktop or into the system tray in the taskbar without permission. If you intend to provide these options, ask the user at the beginning of the installation process. Even this may not be necessary; if some part of the program might be useful on the taskbar, permit the user to turn the feature on (and off) (easily) from the main program, at any time after installation.
There is little more annoying than returning to your computer after a trip to the coffee room and finding the machine stalled on a pointless dialog. As above, if you must ask the user questions at all, gather the information immediately, at the beginning of the process. After you've collected all the required data, let the user know that he is free to leave the machine while the files are being copied and the rest of the installation process finishes.
When installation is finished, tidy up; make sure that shell windows are closed properly and that the desktop is returned to the state in which it began.
There is usually no reason for the user to shut down all of her applications before the installation process begins, so don't ask them to do so. This is a default feature of some toolkits; lobby the vendors of your package to make this message go away. If you believe that there is a reason to shut down open applications, specify the conflicting application or file that must be closed. Don't tell the user capriciously to shut down another product (why does everyone pick on anti-virus packages?). Check for real conflicts and, if they exist, don't dump them in the customers' laps; instead, resolve the compatibility problems with the other product's developers.
In the old days of DOS, the operating system handed the user responsibility for organizing his hard drive and putting products where he found them most convenient. In the GUI world, only the means of launching the program is a real issue; the location of a product's program files should be inconsequential to the user. However, due to history and habit, users now expect to choose the destination directory for a product that is being installed. Make this necessary evil as painless as possible. You might even consider not giving the user a choice, and installing directly to the Program Files directory, certainly in the case of the one-step installation; it's probable that many users would not notice and would appreciate not being interrupted. Calculate accurately the amount of space that will be needed for the installation and some reasonable amount of data. If there is not enough room on the C: drive, offer a default directory where there will be sufficient room. In a tight squeeze, don't forget to calculate cluster slack in the disk space calculations. If files are to be overwritten, subtract the space that they use from the space required for the installation; then remind the user that the older version of the product will be unavailable, back up the older files, and prepare to restore them at uninstallation time.
Everyone has installed a product that posts a dialog saying "A file couldn't be found" and then rudely terminates the installation. Very shortly afterward, everyone has wondered which file couldn't be found. This kind of failure always happens in reference to a specific file. The program knows the name of the file; do your customer and your technical support department a favour by displaying the name of the missing file. However, if the file is anywhere on the installation disk--or any other local disk, for that matter--don't bother posting the message; walk the drives, find the file for the customer, and proceed silently. For those developers worried about potential version conflicts on a CD with multiple files of the same name, the answer is simple: check the version information in the file.
Error messages should be specific. One horrible message in the Microsoft Windows 98 Setup program says that a compressed file was damaged (failing, of course to note the file name), and that the cause may be physical damage to the disk OR insufficient conventional memory. Well... which? The program should easily be able to determine which, thereby saving pointless detective work for the customer or for technical support.
The installation process is no time to subject the customer to an infomercial. For one thing, he's already bought your product. For another, customers are more interested in getting the program installed than watching a spiel on the rest of your company's product line. If you feel you need to distract the user while the product is installing, offer more immediately useful information on the product's features and how to use them. By no means slow the process down to deliver your message. If you provide an online registration service, make it that; don't force the customer to enter a detailed market research survey, and don't insult his intelligence with a "free gift" such as a puzzle that he's not going to want anyway.
Despite your most conscientious efforts, conflicts can occur. Make things easier for your technical support staff by logging the changes that are being made to the system, including changes to the Registry, additions to the file system, and the location of backup files. Customers frequently fail to write down the text of error messages, so if you encounter an error during installation, write the error message to the log file. Place the log in a text file that can be read, printed, or emailed easily.
Make sure that the uninstallation program cleans up the disk and the Registry properly. Eliminate all Registry information that is generated by the main program as well as the entries placed by the installation process. Microsoft's standards require you to leave any data files created by the user. To make this easier, don't default to storing data in the same directory as your application.
Upon an uninstall that is incomplete for any reason, one popular installation toolkit tells customers that "some parts of the program could not be removed", and leaves it at that. This is obscenely vague; why not detail exactly the items that could not be removed? The problem is usually that the program's directory is not empty; this in turn is usually because the customer is encouraged by the main program to save data in the same directory as the program files. If you're saving data files for the customer, tell him that "Your data has been saved…"--and then tell him where the data has been saved. If there is some other reason that elements of the program could not be removed. Offer the customer the opportunity to resolve the issue, and do as much as you can for him. As before, write error messages to disk in addition to displaying them on the screen.
Remember always that the product is not being written for you, nor for your development department, nor for your marketing personnel; the product is being developed for your customers. Avoid complication of the installation process at all costs. Anticipate error conditions, and code around them without pestering the user. Put error messages into an understandable and useful format (see my essay entitled "A Review of Error Messages" for more suggestions on this).
When you think that you've anticipated and planned around all of the possible installation issues for your product, consult with the quality assurance and technical support staff; they'll be able to give a list of things that you haven't considered and that customers have tried. At each step of development, check with experts and novices alike for issues that confuse, frustrate, or irritate them.
All of the standard techniques for reducing defects in software apply to installation programs. Review the design of the program for clarity and simplicity, both for the programmer and for the user. Make the code more robust and maintainable through detailed walkthroughs and inspections. Check return values and handle errors gracefully. Internationalize the product properly; get configuration information such as the name of the Program Files directory from the Registry, rather than assuming the North American default. Work with your program manager, development manager, and configuration management staff to make sure that your files are in all the correct places on the distribution disk. If errors require the customer's attention, provide detailed, helpful messages to allow the customer to correct the problem. Test the installation program obsessively; make sure that it is tested by as many people on as many platforms as you can. Use simple tools--batch files will do just fine for many purposes--to make sure that the right files get into the right place. If short schedules compress the time you need to fix the defects, politely remind management of the cost of shipping those problems to customers.
An installation program is a software product like any other, but because it is the first interaction that the customer has with your product, it requires special care and attention. Make sure that your installation program is simple, unobtrusive, and robust, and your customers will appreciate it-or ideally, won't notice it all.
If you liked this paper (or, for that matter, even if you didn't) you may be interested in a couple of my related monographs, A Review of Error Messages and Effective Beta Testing, which should be available where you got this one.
About Face: The Essentials of User Interface Design and The Inmates are Running the Asylum: Why High Tech Products Drive Us Crazy and How To Restore The Sanity, both by Alan Cooper, contain some interesting (though sometimes provocative) tips for product and installation designers alike. I've recently read The Design of Everyday Things, by Donald Norman. While not specifically about installation programs or software, the book contains many salutary lessons on the ways that people and products interact. Some of those lessons are given by the book itself, which is laid out startlingly poorly, and which habitually refers to itself by its former title, "The Psychology of Everyday Things" and its former context-free acronym, POET. When you consider the subject matter, these gaffes are a a little bizarre. However, it's wortwhile reading. Look for picture of the fuel access door on the minivan--it will remind you of many software products!
"Gain Control of Application and Maintenance with the New Windows Installer", by Mike Kelly, can be found in the Microsoft Developer Network's Periodicals 1998 section. This article will tell you everything that you need to know about the Windows Setup API, which is good; and nothing at all about writing a user-friendly installation routine, which is bad. If you (or your company, or your manager, or your employee) need counselling or instruction in this area, I can help with engaging and informative courses on quality assurance and software testing in plain English that save your company lots of time and money; contact me by for details.
This essay is copyright ©2001 Michael Bolton.
If you liked it, please let me know. If you didn't, please let me know how I might improve upon it. Thanks!
Back to the Essays page...
Back to the DevelopSense home page...
Last revised: 14-Mar-2001
File name: InstallationPrograms.html