The old ABC Wide World of Sports tagline used to say, “The Thrill of Victory and the Agony of Defeat.” Then they used to show a skiier tumbling down a steep hill, no doubt breaking half the bones of his body in the process.

A parallel can be drawn between the sports world and the I.T. world in this regard. The thrill of a successful deployment, the agony of an unsuccessful one.

Here I sit, Sunday afternoon, polishing up my latest application. I am testing it, tweaking it, testing it again. Basically, going through the final paranoid-like steps before it is deployed into production tomorrow.

On the one hand, I am a bit of a nervous wreck. More so than usual with deployments. This isn't my first one, not by a long shot. But it feels like a lot more is on the line this time, and so here I sit in my office on a sunny Sunday afternoon. Running more and more tests.

My application consists of three pieces: two applications and one ASP.NET web service. The applications I have nicknamed CLAP and CRAP and I call the web service WUSS. My employer hopes I am much better at writing applications than naming them.

WUSS (Web Update Service) has been pretty much done and ready to go for a month now. It is not a complex program logically, in that it provides an external vendor access to one of our databases. There are about a dozen methods, so there are several points where it can fail. I wrote set of NUnit automated unit tests for it (almost 100), which revealed a small number of bugs, but made me much much more confident in the code. There should be no problems with this component.

The CLAP (Call List Process) has been mostly done for the two weeks or so, but really solidified on Thursday. It is designed to run once per day, generate a file and send it to a secure FTP site. For the deployment tomorrow, I am planning to run this program manually for the first time just in case something happens. But I have run it dozens of times on my own PC, and so I know it will not crash.

But...

“Not crashing” is not the same as working correctly. The output of my CLAP program is a list of phone calls to be made, divided between several call centres. What if my call list doesn't catch all the calls that need to be made? Or assigns the same call twice? Or assigns them in an uneven fashion between call centres? Those are the big risks with this program. This program needs to run at around 11:30am tomorrow, and I am fairly confident nothing will go wrong with it. I've run this enough times.

The third component, CRAP (Call Resolution Process), runs more regularly (every 10 minutes I expect). After the calls have been completed, it takes the results of those calls and updates our database accordingly. This is the most complicated component logically speaking, because there are dozens of things that come out from this. Depending on what data is updated, different UPDATE/DELETE statements are run.

I still have some “polish” left to do on this program. I want to run through it several dozen more times. I have to do a code-walkthrough (with myself) to ensure that nothing has been missed. I am somewhat lucky with this program, however, in that my CRAP is replacing an existing FoxPro application. Even though there are tons of stuff in the FoxPro app that are irrelevant, I can compare the two programs side-by-side to ensure that at the very least my application performs the same tasks as the FoxPro app.

I would probably like to run this manually too the first few times, before letting the scheduler take over. This program will run in production for the first time at around 4:30 pm, when the after the first calls are complete.

Like I said, I have never been this nervous before a deployment. Usually, my users are complete strangers. Usually, I do not see that much on the line with a failure. Usually, I have easy access to production so I can fix any bugs as they occur, so that few people are affected. But this time, I have a more at stake personally -- I know the people who's lives will be much easier or harder based on my program's success. I see more on the line. And parts of this application are out of my control. For instance, at this company I do not have any access to the production servers or database. I expect to be able to ask for access tomorrow to get it running, but I won't be able to change things on the fly as much as at other companies.

Scary stuff.