I recently wrote about how Jack Whittaker, the largest lottery winner in U.S. history, has been involved in some interesting crimes, both as the victim and the perpetrator.

Well, add one to the perpetrator column. Whittaker has been charged again for drunk driving. Not only that, but this new charge violates his bail conditions for a previous charge. Mr. Whittaker can spend up to 10 days in jail for the bail violation. But it looks like prosecutors are more interested in revoking his driver's license, which is a good idea given his propensity to drink and drive.

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.

The U.S Senate just passed a bill that would raise the Federal Debt Limit by $800 billion to $8.2 trillion. Who wants to take bets on how long that $800 billion is going to last? How much of that money has already been spent since the government has been shuffling money around for 3-4 months already?

And how about a $8.2 trillion debt... Wow. This is mind-boggling. What does $8 trillion look like? There are approximately 6 billion people in this world, most of them living in poor countries (China, Russia, India, Indonesia, etc.) $8 trillion is $1,300 U.S. dollars for every single person alive on this planet. I bet that equals or exceeds the median net worth of every person in the entire world. I wouldn't be surprised.

War sucks.

There's no way around it. There is no such thing as a perfect war. Every war, ever, in the history of mankind, has contained incidents most would consider to be atrocities.

That's not to justify terrible acts. It's actually one reason why war should generally be avoided whenever possible. Every few years, it seems mankind needs a reminder why not to go to war.

So the next time some President tells you that this war will be easy or different, don't believe them. War sucks. Big time.

Last night I witnessed someone giving a demo of Visual Studio Team System.

Much to my relief, they got the exact same error on Portfolio Creation that I am getting. And I noticed their application threw the occasional error at certain places in the tool.

So it's not just me. This product is partly broken. Whew!

Korby Parnell recently stated on his blog that a second beta release of Team System is due out this month. Considering the problems I have been having installing this, I can't wait.

Last night, I blew away the application server completely and reinstalled it from scratch. This is the third complete reinstall (including a fresh Windows OS). I can't count the number of times I've reinstalled pieces of it.

The application server is now working properly. The SharePoint portal web site is back up and running. Earlier, I was getting an error “Cannot connect to configuration database”. I think I know what caused it - I had moved the primary domain server from the application tier to the database tier, without uninstalling Sharepoint Services.

I didn't realize this, but installing SharePoint Services also installs a version of SQL Server. Inside SQL Server is a configuration database STS_Config. Inside STS_Config is a number of database tables that have the name of the server hard-coded inside. I must have inadvertantly changed the name of the server when I moved the primary domain from the application tier to the database tier, because the configuration database has some wrong server names in it.

Once I blew everything away and reinstalled, it is now working better.

I am still having problems with the client tier. I might just blow that away and reinstall as well, since I finally have a working middle and database tier.

As NBA baseketball gets underway this month, some of my American friends may not be aware of one sport that is not getting played this winter: NHL hockey.

Earlier this week, players got together and reaffirmed their position that they are not interested in anything resembling a salary cap. Their proposal calls for a luxury tax. First of all, what does that all mean?

In my view, a salary cap would put a hard limit on the amount of money a team can spend on players. Let's say it's $70 million per year. A team cannot legally spend more than that. Sometimes, there may be things a team can do to try and get around the cap (deferred or upfront salaries), but in general, teams will not be able to spend more than $70 million per year.

A luxury tax penalizes teams that go above a certain salary figure, but does not stop them from doing so. So if the limit was $70 million per year and a team spent $85 million, they would have to pay a “tax“ on the excess $15 million, and that tax money would be paid to smaller teams. So if the tax is also $15 million, Team A pays $100 million for an $85 million team, and Team B gets $15 million in free money.

The ultimate goal for player-owner negotiations this year is to lower salaries and save the teams money. Under the salary cap scenario, total team salaries would never exceed $70 million per team. Most small-market teams would never be able to afford the cap limit, so the net effect of a cap is an immediate freeze on salaries -- even a bit of a rollback in big markets like Toronto or New York. This is what the owners mean by cost certainty.

Under the luxury tax scenario, total team salaries would probably continue to increase. For instance, a team can exceed it's cap by $15 million, and this would allow another team to also spend $15 million more. Smaller teams can afford to increase their salaries from the “tax” monies they receive. Larger teams would have to pay a bit more to put the same team together, but that might not stop larger teams. It's hard to see where the “savings” are in the player's offer.

Of course, this only makes sense. The players are only interested in one thing: that their salaries continue to go up. So they can come up with a proposal where the owners pay more, that also conveniently results in the players getting more (the tax monies are spent by smaller teams, resulting in increased salaries across the league).

What I'd like to see is the players at least talking about the details of the cap. The owners obviously want to drive costs way down, so their idea for a cap will be low. Why don't the players negotiate for a high cap? Or a cap with a few loopholes -- 1 or 2 players per team are exempt from the cap. I mean, the notion that they can just “make a wish” and a cap would disappear?

This is why the fans are largely behind the owners more than the players.

The players have a standard refrain when asked about a cap, “A cap just protects owners from themselves. If salaries are so outrageous, why don't they just stop offering large contracts to their players?“

That statement oversimplifies the situation. Each year, every owner is trying to make a competitive team -- one that will make it deep into the playoffs. They want fans to come out and see the games, and they want the extra revenues from the playoffs. Individual players also build up a fan-base in their cities. Toronto loves Mats Sundin and Tie Domi, as it loved Wendel Clark and Doug Gilmour. There are certain players who can ask for, and get, a little bit more than their stats say they are worth because the owners don't want to upset the fans.

The problem is, every other player in the league will now look at what Mats Sundin is getting, and compare his stats to theirs. “Hey, I scored as many goals as Mats. I want the same salary.“ You also get players who sign deals based not on their performance but their potential, and then don't live up to their potential. So again, players compare themselves to a 5-goal-per-year scorer and say, “I want more than him“ even though the other player's contract was not based on stats either.

Maybe we should go to a pay-for-performance model? For each team win, each player gets $X. They get $X/2 for each team loss. Players that are popular with advertisers and fans get a big bonus. So if you are a no-name player on a losing team, you might have to get a summer job.