It makes me tired just thinking about it.
The biggest pain point for me is tracking down all of those installable bits each time I need to do a reinstall. Some vendors are nice and ship a driver cd or driver helper. Dell does this, but the interface it provides is pretty bad and is a more painful than going to the Dell support website and downloading things yourself.
Ultimately, this boils down to wanting to avoid the time and effort required to find the right drivers for the right system. The cost (time, patience) of finding each driver or support software is relatively fixed, so let's optimize the process and only perform this "find the right driver" once.
The end result we want is really a local, central, and organized repository of things we need to install on workstations and laptops. I like subversion for solving this. You may not want to use subversion, or any revision control at all, and that's fine - it is just a means to an end of "local, central, organized repository of software/drivers."
My search path for finding a given piece of laptop software usually starts with the hardware model, then the thing I need (network driver, or whatever), so it makes sense to use that order in the subversion layout: Such as /vendor/model/category - where vendor is the vendor of your laptop or workstation. This saves you from having to remember that a given laptop has a broadcom network chip, you just know what laptop you have and that it needs a network chip.
- Network drivers for a Dell Latitude E5400
- Audio driver for a Dell Latitude E5400
The next step is getting those drivers portable and making them available to fresh-installs that may not have networking. Doing an svn checkout to a thumbdrive lets you easily get these drivers to the host that needs them, if there's no network on that host. Updating your thumbdrive is a simple 'svn up' (or right-click, update via Tortoise SVN in Windows) and you're done.
Once you are in this position, you can start working on automating the process of driver and software installation. You can begin writing automation scripts (batch, vbscript, AutoIt3, etc) to make your software installation an unattended process. Keep these automation scripts in the same directory.
You may want to consider creating a separate subversion repository for this data. The reason for this is that adding all kinds of large files to a smaller, code-oriented repository may unnecessarily clutter things. Larger repositories may take more time to back up and restore, and some folks may check out trunk for code work and 'svn up' now fetches those installers, and additionally, existing repositories may have access controls that are too strict - you'll probably want anonymous checkout, or use a user account that is unprivileged and only has access to the software bits.
Finally, since we're sorting by vendor and model, you can extend this idea to include things like switch firmware and other versionable blobs.
This practice of having a local, central, and organized repository of drivers and other software packages helps you avoid repeatedly having to search for the same piece of software multiple times.