The Gold CD
I try to be pretty conscience of what I install on a PC whether itâ€™s a test PC or my own laptop. So I was surprised when I was working with Mike Kelly this weekend and he said well just drop Ruby onto the test machine. My reflex was to safeguard the laptop. Nothing against Ruby, I just like to control my environment and wanted to think about what the install might do. A little investigation shows that a Ruby install adds 3,000 folders and 21,000 files. Yeah twenty-one thousand files.
Ruby also added 48 keys to the registry and 109 values. I should mention that I spent several years testing installs so my reflex comes from experience. One product I tested for a number of years, and at the end of the dev process, Iâ€™d test the install as we worked towards the gold CD. (The gold CD is the CD that went to manufacturing. Iâ€™ve also done sample tests of the manufactured CD to ensure the production quality of manufacturing. I could digress on the topic of sample size but not today.) Iâ€™ve never been able to just install an application since then. In fact, I installed Ruby on a scrap laptop first to check out the install. Old habit.
This also led me to find once again that a couple of old favorite utilities donâ€™t work well with Vista. This isnâ€™t a gripe against Vista, every now and then I go through a pruning process of my test utilities for different reasons. In fact, I blogged about the tool I was hunting for this past weekend. I needed a better tool to checkout dlls loaded in the environment.
So a couple of points. One, if Mike Kelly was willing to drop software onto a laptop without knowing what (if anything) it might add or alter to the environment, then ouch, no doubt testers could tamper with an environment unknowingly. I joked with Mike about this for the balance of the weekend. It was pretty funny. So you might want to think about how you may alter an environment as a factor in the old â€œit used to work on my machine.â€
Did you know that even the order in which you startup applications can matter? How? If multiple applications use the same dll and the same dll is loaded on a workstation in different directories â€“ then the first application started loads the dll. Itâ€™s possible (Iâ€™ve witnessed this) to have the next application use the loaded dll instead of calling the version it may need from a different directory. See shared in-memory on the following reference and you can see why I want/need a detailed view of the dlls loaded. DLL hell can get a little crazy and take some meticulous tracking to figure it out.
If you want more details on install testing, I wrote an article on installs for Better Software recently, you can find it here. Itâ€™s called Navigating the Install.
A second point â€“ when youâ€™re trying to isolate factors, consider the environment. An investigation in this direction has often resolved the â€œit works on my machineâ€ syndrome. Iâ€™ve used tracking tools to see what a developer has loaded on their workstation versus my test PC. On my cleanest personal laptop, I keep a running notepad file with the date and what Iâ€™ve installed so at least I can backtrack and possibly determine if a recent install is a culprit. Itâ€™s a minor chore and I think worth it. I track toolbar and browser add-inâ€™s too because anything dropped on a PC counts.
21,000 files huh? Mmm.