Only on a Friday....

I typically average a nine hour work day at the mines. I'm actually present there for longer than that, but I try to squeeze in at least fifteen minutes to grab a quick lunch at my desk. On Fridays, though, I try to treat myself to an eight hour day. It doesn't always work out that way, of course, given that the demands of computer work are no respecters of regular hours. As the clock inexorably (but oh so slowly) works its way towards my hoped for departure time, I start to tense up whenever someone approaches my office door. And so it was yesterday.

To fully understand what occurred yesterday requires some back story. Back at the beginning of the year, one of the larger insurance companies that we work with on behalf of our 3,800 customers approached us with a problem that they had. By "approached us" I mean "made a demand," and by "a problem that they had" I mean "a problem that they had that they were going to make our problem."

This, sadly, is not unusual, and it is the nature of our business relationship that we pretty much can never say no. As with many demands of this sort, meeting the demand would require the hurry-up development of a software application. Which is really just a fancy way of saying "I would have to deal with it."

In a nutshell, new government regulations would require that our customers be notified of an issue that they would have to rectify within five business days or lose hundreds of dollars in reimbursements for product that had already left their stores. Oh, and by the way, the clock was already ticking on the first set of claims. Beneficent as our government is, however, rather than five days I had thirty days to get our customers in compliance or face the loss of tens of thousands of dollars in reimbursements would not be paid to them.

Setting aside the work that I had been planning to do, I got busy. First up was the requirement to import that data file provided by the insurer into our databases. Unfortunately, the data file was provided in Microsoft Excel, by far the worst possible choice. It's not that I couldn't "read" the file in an application and push the data into a database, it's that it is inevitable that at some point in the future the format of the spreadsheet will change and no one will bother to tell me. I have been down this path many a time, but my desperate pleas to send the file in a more reliable way fell on deaf ears. Not wanting to be plagued with having to fix and rebuild the application every time the format changed, I built a function in my program that would sample the first three rows of data in the spreadsheet and display the values to the user as a kind of pre-test. I provided arrow buttons that would allow the user to position the data correctly on the screen and proceed with the import.

Quite slick, that, even if it is me that's saying so.

There were, of course, all kinds of other things that I knew would someday go wrong. I knew, for example, that it was just a matter of time before Customer Service received a call from a customer needing to have a report sent again. I added a function to my Customer Service program that allows them to browse through the archived reports for a store, view whichever report was needed, and elect to re-send it via fax or email at the press of a button.

I also knew that it was just a matter of time before a store called to ask us to send the reports to a different person in their store, so I built in a function to re-assign the name, fax number, and email address for the recipient of a report. I even made it possible to move a store from one recipient to another, just in case someone at a customer's store changed jobs.

Truly, I thought I had thought of and solved every possible thing that could go wrong. I even ran the first few cycles myself to make sure everything worked smoothly, then had a gathering with the users that would have the primary responsibility of running the reports, plus a small group of secondary users that could fill in should the primaries not be available.

And so it was that when I saw a Customer Service agent headed my way on Friday afternoon, I was poised for the worst. "Hey, Dave, I have a problem with one of the reports."

"Oh, no," I thought, "what could possibly have gone wrong??"

"What happened is I got a call from one of our customers," the agent told me. "He called because he received a report that doesn't belong to him. His name is Hussein Hussein, and it looks as if we have a different customer of the same name, and the report got sent to the wrong one."

"Wait," I replied, "we actually have two customers named Hussein Hussein? I would have been surprised to learn that we had one!"

But remember how I said that I had thought of everything? Well, I had actually thought that we could potentially have a name collision, although I would have bet on it being John Smith or Tom Jones, or something like that. I never foresaw Hussein Hussein as a possible problem, but this was one of those occasions where fixing it for one case fixes it for all. It would simply be a matter of using the application to move the store from one Hussein Hussein to the other. That said, in cases like this we like to ask the customer for a middle name or initial that we can use to differentiate one from the other, lest the confusion recur and we have to go through the whole thing again.

As it turns out, this particular agent was on the ball. He had already contacted one of the Hussein Husseins and gone to our Operations group to have his record updated to include his nickname. This Hussein Hussein was forever more to be known in our data base as Hussein Shane Hussein. All I needed to do was move the store to the correct Hussein Hussein and I was done. I might get to leave on schedule after all!

Not long after all of this transpired, the agent was back at my door.

"Dave, Hussein Shane Hussein called, and he is livid at having received one of the reports with someone else's data on it."

That made no sense to me at all. In fact, it should have been impossible. The reports are all generated from within my application - there's no room for human error. I said as much to the agent.

"Well, I thought you might say that, so I had him fax a copy to me." Ah, a sharp one, this fellow. And sure enough, upon inspection I saw that there were two reports, each having a different store name and recipient name in the top block that I reserved for such things, but an identical list of claims on each. To say that my flabber was gasted would be quite an understatement.

"Okay, this is surpassingly odd and there is naught to do but to consult with the person that handles these things."

Yes, I often do talk like that at work.

At this point, it was clear that my early departure was no longer in the cards; the only remaining question was how late I would be. There was something north of five hundred dollars at stake here - there would be no leaving until this was rectified. Off we went to visit the user that handles the sending of these reports.

My first question to her was whether she had attempted to re-send the report.

"Yes."

I then told her that we had gotten a call from Hussein Shane Hussein and that he was angry about receiving someone else's data.

"Oh! I must have sent it to the wrong store."

"But I'm not clear on how that could happen," I told her, "since I've already fixed the contact information for both of them. It should have worked automatically. Besides that, I'm not at all clear as to how the data got crossed from one store to another. The re-send function doesn't re-generate the report, it just sends the archived original."

"Oh, I did it manually," she told me.

"Really? In what way?"

"Well, I printed the report, used WhiteOut(tm) to cover up the store information, printed the other store's information, and taped it onto the report. Then I sent it from the fax machine," she explained.

A long pause....

"Oh," was all I was able to say, feeling as if I had been punched in the gut.

I honestly had never even come close to thinking of that possibility!!

At that point, all I could do was shake my head, go back to my office to grab my stuff, and head for Silke.  I was in no mood to deal with the heat and noise that comes with my thirty-five mile highway drive home. I left the top up, turned on the A/C, and hit the road.

Which reminds me: I've noticed something about Silke. When driving with the top up and without the radio on, she creaks and groans quite a bit on bumpy roads. This is pretty much normal for convertibles, but for some reason I didn't expect it from a Mercedes.  Not to be overly crass (that's your warning that I am about to be overly crass, by the way, so avert your eyes if you must), but it's kind of like hearing a pretty girl fart:

You know at some level that surely they must, but it's still somewhat jarring to hear it for yourself.

Saturday worked out well for an early start at the hangar. Pete agreed to an early start as he still had quite a bit of work to do on the surprisingly complex tail cone installation and I wanted to do some more work on the cooling duct. The avionics will be arriving soon, so I'd like to wrap up some of the loose ends that I've left, well.... loose.

One of the things I haven't mentioned about the cooling duct is that mine exhibits the same problem as many others I've heard about. The problem is that one of the springs that hold the muffler onto the exhaust headers rubs against the duct. This is what is known in the airplane builder's vernacular as "a bad thing." The fix for it is to cut a hole in the duct and build in a "bump" to give clearance for the spring. It is that job that I wished to complete today.

Before I could do that, I had to "fix" the duct's location against the lower cowl so I would lose all of the positioning work that I had already done. Fixing the duct in place is accomplished by drilling into its top flange and clecoing it in place.

Once it is secured, the lower cowl can be removed and the same thing done with the lower flange.

I had marked the spot where the spring was rubbing before removing the cowl.

All I had to do then was grab the Dremel and cut a big hole in the duct.

Hole: accomplished!

I have plenty of fiberglass cloth scraps left over from the canopy work, so I cut a couple of pieces to form the bump.

All I had to do then was mix up a batch of epoxy resin and wet down the patches. Then I just pushed them through the hole. Gravity kept them in bump shape while the resin cured.

Meanwhile, I shifted gears and did a messy job on the exhaust springs that I had been putting off. The idea is to fill the springs with RTV. According to Vans, this will keep that from resonating in synch with the engine, the worry being that the vibration of the resonating springs will cause premature wear and tear on them and on the muffler/headers.

As I said, it's a messy job. How messy?

Abattoir messy.

After cleaning up from that act of butchery, I decided I'd like to do something a little more delicate. Installing the Exhaust Gas Temperature (EGT) probes looked easy.

And it was.

At first.

Getting these wires put together was surprisingly difficult. There's generally a whole lot of airplane getting in the way of everything I try to do these days.  I guess that's a sign of progress.

The other side was much easier, but there was quite a bit too much wire left over. You can't change the length of the wire on a thermocouple because it will change the resistance of the sensor, and that in turn will cause erroneous data to be displayed. I just coiled the excess wire up and bound it with tie wraps and silicone tape.

I also decided to do something about the two little sensor wires that were just kind of floating around alongside the engine. I wrapped them together with some wire wrap so they would behave as if they were a cable, rather than two wimpy little damage-prone wires.

That was enough for the day. There was mowing and weed whacking yet to be done back at the palatial estate.