On one software project long ago (in the time of Windows NT4), I hated the installer that we had. It had been written by a developer who had been more or less thrown out of other teams, and it was decided that the installer would be a safe thing for him to do. But then the bosses were too busy and nobody ever had time to review his work.
Later, I was doing software maintenance on the project, and I got the opportunity to find out what was wrong, and to fix it. It turned out to be fascinating learning.
The reason that I hated the software's installer wasn't only that it was very slow (it took about 15 minutes to install the software). I also hated it because, for most of that time, not only was there furious hard disk activity with no progress displayed, it refused to ever update the screen at all, so it looked like it had died, and you had to just wait to find out whether it was working or not.
When I was given the task of updating the installer, I started by doing some profiling (run monitoring software and see what on earth it's doing), and was horrified. The reason that it took so long was how it dealt with 280MB of digital map files. They came zipped up into a cab file. It unzipped them, then zipped them up again, and then unzipped them a second time. Then for good measure, it did the whole thing a second time, from a second copy also stored in the installer, overwriting the first copy.
So there was more than one problem. Just getting rid of that second copy would be good, but if he had been so unaware of what he was doing as to make that mistake, it was worth looking for more.
The biggest problem was that there is a whole methodology for how you deal with things like digital maps - or anything that normally isn't going to ever change. Best practice is to keep them separate from most of the installation process, and unzip them just once.
He had used InstallShield, which was (and still is) pretty much the standard solution for creating an installer, but he obviously never learned how to use it properly. The first step was to figure out whether to keep using it or to change.
Horses for Courses
You only need enough of an installer for whatever it is that you need to achieve. InstallShield costs money because it does everything that anybody will ever need. But if you have a look at the freeware and shareware communities, InstallShield is seldom used, most developers use either NSIS or Inno Setup, both of which are themselves freeware. They lack some capabilities such as protection of your software from theft (by decompiling the installer itself), but are simpler to use.
I chose Inno Setup as being adequate for what we were doing - and at a time when many different versions of Windows were around, its ability to detect the version and automatically adjust was nice. It was easy to do nice cosmetic things such as adding a logo or two in the installer GUI and making use of the icons that had already been designed for the software we were installing (because eye candy sometimes does make you look more professional).
There are several accepted ways that you put together a Windows installer. For example, you use %systemroot% to find out where Windows itself is installed (instead of assuming it's in the default location).
When we tested the old installer on Windows 2000 and XP, it turned out that he'd done none of that, so that the installer wouldn't have worked at all if Windows was set up even slightly differently to normal. But, sometimes, you have to be lucky - in Windows XP, it turned out that the only reason it worked at all was because the files that he shouldn't have been installing on XP were being installed at the wrong location, where they would never be used anyway - so he'd made two different mistakes which cancelled each other out.
So I rewrote the installer completely, in Inno Setup. It saved a lot of time whenever we had to update the installer, and it got the installation time down to about two minutes - with a progress bar that actually worked. And I had learned quite a bit about installers.