And the light emerges from the tunnel

At noon today we had just one issue to be resolved. After lunch we came back and attacked it. At that moment I made a mistake that cost us about 3 hours and meant I couldn't leave today. A simple mistake; I didn't refresh the display (it's not as simple as hitting F5 - there are about 5 steps needed to make the hardware believe it's seen a change, if you're faking it - I didn't do them). By 4PM I knew both that we were working and why the thing I thought wasn't working really was working even if I didn't think it was. Convolution city huh?

We did one final dry run and called our customer over to see a demo. It worked flawlessly!

Our demo consists of taking a tray or two of semiconductors, loading them into a robot that picks each semiconductor up, inserts it into a test board, runs a quick functional test and unloads those that don't work. The board then goes into a burn-in oven where each semiconductor is tested at high temperatures. When the burn-in run finishes the board goes back to the robot and is unloaded. The robot unloads the devices that passed all tests into that tray; the ones that fail are unloaded into other trays depending on which test they failed.

We had to fake a failure during our burn-in run. We marked the chip that had been falsely failed and ran the unload. It was almost poetic to see the devices unloaded and to watch the progress of the marked chip to the failed tray! Even more magic; seeing every other chip make it to the 'passed' tray. Handshakes all around and a glass of beer an hour later to celebrate success (we made sure the sales guy, Kevin, got the tab ).

Along the way I had to make the odd tweak or two to the software; it's a DCOM component written in C++ running on one computer and called from a VB app, for which I have no responsibility, running on another computer. That's a fun debug. Source code I've never seen making calls through DCOM to source code I didn't write but have to maintain . Oh, did I mention there's a third machine involved running a database?

But we got it going and I checked all my source code changes back into our SourceSafe database in Phoenix. Gotta love VssConnect. Not long after I realised that this job would require me to travel frequently I investigated our options for remote access to a SourceSafe database. VssConnect seemed the best choice so I tested the (time limited) free download. It can use http as the transport mechanism and, given that our primary customer has a very aggressive firewall that blocks almost everything except http VssConnect seemed like a good choice. So it has proven to be. I can get to our SourceSafe repository from home, from Japan, from the Philippines, France, you name it. I can check out files, make changes and check em back in.

Contrast that with how it was half a year ago, when my predecessor was still working on the code. He'd send me emails with snippets of changed code and the request that I merge lines 457 to 501 of source.cpp with that snippet. Without the context it was damn near impossible to be sure I was making the right changes. More than enough incentive to go find an internet capable solution. Once I had the licenses in hand I sent him an email; 'I will no longer make any merges for you; check the files out as you work on em and check em back in when you're done'. It took probably two iterations to get the point across but eventually it sank in. Maybe that's why he refuses to make any further changes. Whatever. If he's not making changes it means I have one less source of concern!