I arrive at work about 30 minutes after leaving the toll plaza. One good thing about getting to work at 08:10 is that there is lots of parking. I've gotten to work at 08:40 and there's still some easy parking, though filling up fast with a constant stream of cars arriving at Oracle. I get to park a couple of hundred feet from my building and then walk in, not fully awake yet. It's still quiet. Kind of nice really as there aren't that many people around and I can set up my PowerBook and relax a bit. When I get to work I usually spend a half hour surfing the Internet -- catching up on Macintosh news and a few other news sites that I frequent.

It's now 09:15 and still haven't that call. There's a slight problem with one of our telephone switches -- we can't get the Rockwell switch to transfer a call with an analog line (an analog line being a standard phone line, most bigger companies have PBXs and ISDN phones which provide more information and capabilities than analog phones). We called Rockwell support like three weeks ago and they've been trying to help. Gave them log files and they can dial in and look at our setup. Why only yesterday I called Ray (our primary tech contact for this ticket) and he said that he should be able to get an answer from another expert by 11:00 his time today, which is 09:00 my time and hence why I was here in the morning. Just in case I had to test some fix and it didn't work, Ray could try another tack. Alas, sometimes people just don't call.

But at 09:30 I do have a weekly conference call to attend. Usually I do this from home which can be a slight problem since I can't look up information and have to rely on memory when I make my report. This call is with Cisco, who we've had a partnership for the better part of a year. We're trying to expand our product to integrate with Cisco's Intelligent CallRouter (ICR, though it's also termed ICM and Geotel -- it's gone through a few name changes in the last year or so). The ICR talks to the switches for us and talks to us in it's own language. The intent is that we only have to worry about the ICR protocol and not the protocol of every switch we support.

There's also another product we've been using to do the same thing, called Computer Telephony Connect, or CTC, made by Dialogic. CTC has been around longer than ICR and it tries to do less things, both of which make it much more stable compared to ICR. From the get-go we've had many problems with the ICR -- problems that I inherited when I came to this team -- and Cisco has been very slow in solving our bugs. Hence these conference calls were instigated so that every week we could listen to the Cisco reps squirm and fidget and say that no progress had been made on their side. At least that's how I've seen it in the six months that I've been in on these calls.

Fortunately, they did finish their big patch for us which fixed most of our outstanding problems (at least for my product, they have other bugs pending for other switches that other people on my team are working on). The last open problem was closed during this call -- they couldn't fix it but it's not a big problem anyway -- and I didn't pay too much attention to the other parts. An hour later we were done and it was now 10:30. Still no call from Rockwell and by now I've given up waiting.

Then I remember that I'm supposed to have my ICR-Nortel environment ready for our QA group so that they can start testing today. Developers do unit testing, which catches a lot of basic problems, but we don't have the time to really test our products, and we're too close to the product. It's QA's job to do that final round of testing to certify that a product is good enough to ship. Note that we -- as well as every other software company -- ship products with known bugs. What with all the products in CRM, we have hundreds of known bugs by the time we ship.

Most of the bugs are what we refer to as P3 or P4s; minor bugs for the most part. Either bugs that are serious but should never happen with normal users or little display problems or other things that will bug some users but not all. So it's a matter of prioritizing. Is it worth it to fix this bug or to work on new development? We try to fix all the easy ones, but that still leaves plenty of bugs. Should I spend two days tracing code (and the hard part is tracing other people's code -- I can't just pass the bug to some other developer unless I *know* it's their problem) for a bug that 99% of people won't notice and even then won't affect their usage of our application?

(continued)