The hardware platform upon which your new code is going to be deployed must be in place, running, and trusted well in advance of the scheduled application testing.
Complying with Rule Zero will an amount of time equal to n, where n is slightly greater than the reasonable amount of time allotted for hardware setup in the project schedule. No matter how close the hardware is to something you’re already running or how simple the setup process is, n is by definition longer than you think will be necessary.
Until you have started testing the new code in an environment that is functionally identical to production, you don’t know how it’s really going to behave.
So What’s With the Rules?
Basically, Rule Zero is the only one that really matters here. If you’re mindful of Rule Zero, you can handle all of the other hardware related rules. Why do I bring this up now? Because I jotted down Rule Zero after seeing somebody else’s project go all pear shaped, and spending time thinking about the reasons for the problems that the project encountered. I noted Rule Zero down in a few places, actually, so that I would always remember it going forward.
Oddly enough, other people’s mistakes don’t really make the impact of one’s own mistakes. While I still believe that our current project had enough margin for error built in to keep us on track, it is abundantly clear now that I ignored Rule Zero. Getting the new hardware took longer than expected, with all sorts of weird glitches. Getting that hardware set up is taking longer than expected, with all sorts of weird glitches. All this despite the fact that we’re basically setting up machines that are virtually identical to a dozen others that have been up and running smoothly for months, if not years.
I’ve done it myself now, so I hope and trust that this will burn Zule Zero into my memory.