I'm not sure about coding theory or even what it is (although I am a software developer). Most of this you will notice if you work enough around computers (which you will be undoubtedly doing, looking at your signature). However, writing software, especially drivers, helps when analyzing this stuff.
Despite seeming so convoluted, there is a pretty simple heirarchy to driver and application installs. Either something depends on another library/app or it doesn't. Following that logic, you almost never have to worry about installation order. All modern operating systems hide the complexity from users. Even for applications, a lot of them will inform you if their prerequisites are not adequtely met. Sometime, even out-of-order installs w/drivers will not cause a problem.
As for IRQ settings, the case is not so clear cut. In the past (not that long ago, actually), IRQ settings were determined by jumpers on the hardware. Nowadays, though, such pieces of equipment are rare except in niche markets. The IRQ is set by, in most cases, a PnP BIOS and the OS. In those cases, the OS will most likely determine which IRQ to use by quering the hardware for any restrictions it might have. Now, most of the time, you needn't concern yourself with the IRQ settings. The OS should not double-up on them unless it has completely run out of empty IRQ slots to hand out. The way you can check if there is a harmful conflict (some IRQ conflicts are benign) is to go to your hardware settings (on Windows 2k/XP: System Properties --> Hardware --> Device Manager). However, it has been a long time since I have seen an IRQ conflict on my system.
If you have ever written or seen the internals of a driver before, you will notice that a lot of it depends on how the hardware was manufactured. For example, a lot of hardware used to have the IRQ settings hardcoded into it, which led to all kinds of problems. Nowadays, most drivers do not have to concern themselves with such things at all. Instead, they can usually focus on just providing an interface to the hardware through the driver, and leave the extremely low-level stuff to the OS to figure out.
Hope that helps,
zakaluka2.
