The Empty Guarantee

Today I received an e-mail requesting that I leave a block of time open in my schedule for an interview. Apparently this was to determine whether I would be placed in a position with another project. This seemed very strange since I had already interviewed with the project, done well, and received a memo from Human Resources stating that I was going to be reassigned.

So without delay I called up the person who sent me the e-mail. She was familiar with the previous interviews. But she stated firmly that I did not have a job with her project. The prior interview and transfer letter was null and void. I thanked her for the information.

Next thing I did was call up Human Resources. Left them a message. Have not heard back from them. So I called my project manager. He has a cell phone and tells us all to call him when anything comes up. I spoke with him and told him about the disturbing conversation I had. He then went to speak with the project manager on the project where I was supposed to have had a job. It seems that they got a smaller budget for the next release of their software. So they are reevaluating what developers they can pick up.

Great. So now I have to go back and interview with the project again. But this whole scenario is very unsettling. In the past, senior management made promises that they would find us all jobs when our current contract ran out. I guess those promises were only as good as the budget they could arrange for future contracts. This is after all a business. Now my mind is racing back and forth, thinking about how I may have very well been conned. Perhaps the smart employees are the ones that have already bolted. We shall see how this pans out.

Telephone Problems

I place and receive a lot of business phone calls at work. Two weeks ago I was on a teleconference call. The host of the call hung up, and the call hosed my phone. It just displayed the last number dialed on the screen. I could not get a dial tone.

So I called up the Help Desk. They patched me through to Nortel since they service our phone system. A trouble ticket was created for me. Then I went on vacation. I got back to the office a week and a half later. My phone was still broken.

I called Nortel up directly. Apparently they tried to fix my phone, then left me a "voice message" stating that they were done. Only one problem. They did not fix my phone. This time around, some guy came out and manually reset my line in the telco closet. And to ensure there were no further problems, he gave me another phone. He said this was not really necessary. But due to the circumstances he wanted to make sure I was good to go.

Everything seemed back to normal until I received my first new call on the working phone. Apparently the ringer volume was set up to max. I jumped out of my chair when I heard it. What kind of company sets the default ringer volume to loudest? And a few tests and scrolling through the menu options on the phone, I think I am back to normal. Sheesh. Come on Nortel. Keep my phone up and running.

Software Changes

I spent most of my day training the new team that will take over the maintenance of our software. The new team was especially interested in the new features we had added in the last year. We have been very busy this year. So the change list was long.

Luckily I had conducted a Customer Technical Review with the end user of our applications. So I grabbed my 20 page overview of the application changes. I went through this presentation with the new developers. It was well received.

Next I reviewed the most recent big changes that we did for our customer. These were last minute high priority requests that our customer made. I described each of the changes and how they impacted out applications. In addition, I pointed out some of the weaker parts of the design and requirements. These guys need to support the system now.

By the end of the day I had to get back to my normal work. So I escorted the new developers out of the building. When I got back to my desk, our client's headquarters had called and e-mailed me asking about some of the details of the recent software changes. I quickly scanned the new code to make sure I had my story straight. Unfortunately what I found out is that the customer wants some different business rules to be implemented. I spoke to our Project Coordinator to see how we would respond to any requests for this change in our last days on the project. The Coordinator told me that the customer had to submit a formal change request, and the new contractor would have to do it. Good luck to them. They will most definitely need it.

Training

Another company has won the maintenance contract that I work on. We have a couple weeks until our contract is up. The new team has already been assembled. They requested some time with us to help train them. This seemed like a reasonable request.

When the new team came to meet with me, I asked them what they wanted to get out of today's meeting. I assumed I would just walk them through a normal day of customer support. They agreed that this would be good. However they also wanted to know all the new features we added to our application suite this year. I told them that would take a long time.

So I went to one of our developers, and took a trouble ticket from him. This was a real life example that I would use to train the new team. I reviewed the text of the trouble ticket with them. Then I made sure we all understood the behavior in the application that the users experienced. Then I went over the behavior that the users were expecting.

This particular trouble ticket was very thorough in that it provided specific examples of the problem. One of the examples did not make sense. So I emphasized that when something like this happens, you should overcome any reservations and call up the users and/or system administrators. Right there in the conference room I called up the sys admin who submitted the trouble ticket. He clarified the details which seemed strange. We we now ready to run with the problem.

I showed the newbies how to log into the Production database and run queries to see the sample data. Then I found some data in development that was similar to the problem production data. Made a couple updates to my development data to exactly match. Then I followed the steps the users listed, and we were able to duplicate the problem. This was all done in record time. We got lucky.

Unpaid Overtime

I recently came back to work after a nice vacation. The project my team works on is about to end in a month. We are all scheduled to move to another project in our company that is similar to ours. Just about all of us had interviewed with members of this project, and received officials letters informing us of our upcoming transfer.

The first thing I heard when I got back was that there was another round of interview with this project. This seemed strange as the transfer was supposed to be a done deal. But here was the real kicker. A developer told me he was grilled about being required to work 60, 70, or 80 hours a week on the new project. And apparently they are all on call 24 hours a day.

There must be more to this than meets the eye. I am awaiting another round of interviews myself to get to the bottom of this nonsense. All of my team members are salaried employees. It makes no sense to be working on a death march. We get paid the same regardless of hour many hours we work.

I hope my first task on my new project is not to write a white paper on the drawbacks of working extra hours. However this may be the route to go. There comes a time when you need to make a stand against insanity. I think the right way to go about this is to come in with some hard data on the price the business will have to pay if the old "more hours mean more productivity" is not dispelled.

Black of Hat Blog

While on vacation from work I have done a lot of things. I visited a casino to do some gambling and lose money. Still working on the house, replacing my broke down oven with a shiny black new one. And I have been writing some software that is featured in my new blog Black of Hat.

The first free program I have posted to my Black of Hat Blog is one which launches Internet Explorer and navigates to sites of your choosing. I wrote the application using Visual Studio C++ which I am most familiar with. It is a self contained executable with no installation other than copying the EXE.

I already have an idea for my second Black of Hat program. It will be a web site crawler which extracts a unique list of URLs. Now if I can only finish up and post this program by the time I return to work, I will have had a successful vacation.

Going on Vacation

Today was my last day for a nice long vacation. The plan was to go in, wrap things up, and say goodbye to everyone. Of course as soon as I entered the building, everybody came running to me to try to talk about the emergencies going on.

Apparently our customer's configuration management team had delivered the wrong version of the application to the users. And all holy hell was breaking loose. I had to tell my whole team to leave me alone while I determined what had happened. As soon as I identified the problem being with customer CM, not our company, the project manager breathed a sigh of relief.

Many trouble tickets that got opened today were flase positives. They were due to the fact that a really old version of the application got installed everywhere. The good part about this was that they were easy tickets to close out once users got the correct version of the application. There is a saying that goes "when it rains, it pours". Well it decided to pour down hard today. My phone stopped working right in the middle of a conference call. It ceased to function for the whole day. So I had to call into my voice mail from different phones to catch all the messages people were leaving me. Nice.

The real kicker happened late in the afternoon. But some unusual bad luck, a high priority trouble ticket had come in. But the ticket did not show up in our inbox. The customer started complaining that nobody was working this high priority ticket. By this time the Help Desk had gone home. I was going to sneak out the back door, but I warned the closest manager that once again things were going to get rocky. He talked me into doing a quick initial investigation, and providing the team with some information to help them get through this tough ticket. I tried calling the user but he had left for the day. So I went back and reviewed how I handled the last trouble ticket similar to this high priority one. And I tried to explain in English what the normal operation of the software was, what the perceived problem was, and how some actions by the user could make the software appear faulty.

My deep hope is that my vacation does not get cut short or cancelled due to this latest high priority problem. My fingers are crossed.