Prasad mentions that he called Pick, waking him up apparently. When asked why he wasn't here for the meeting, he reportedly mumbled something like "I'm not supposed to be there." Sheesh, he makes us all go and doesn't support us? Oh, the heartbreak, the total disillusionment, the complete feeling of betrayal. In any event, most of the Call Center developers who happened to be around this morning show up, several claiming that they never got any email and it was lucky that they ran into so-and-so who told them about this meeting.

At 10:15 Holger Mueller, Vice President in charge of Call Center Development walked in. Pick is in charge of West Coast Call Center Development, John Kuzmicki is in charge of East Coast CC Development, Holger is their boss and has a few other groups under him. Anyway, he comes in and asks how far we've all gotten on the meeting. "We haven't started," comments Norman. "You haven't started?" "We can't get the audio working." "What, don't any of you know how to work the equipment?" he says jokingly in his German accent. Holger is a good guy, the kind of guy Pick gets along with easily, so that should say something.

While Holger is trying to figure out the video system, poking buttons here and there, he asks anybody to use his Palm Pilot to get the phone number of his assistant. Nobody moves. "What's the matter?" "Err, I don't know how to use a Palm," says Norman (right next to Holger, I was on the other side and I don't know how to use a Palm). "Don't any of you know how to use a Palm? Good thing you're not hardware developers or CRM would be no more!" Eventually we do get everything working and we start the meeting (presentation really).

So we're all here to learn about "leapfroging" (mispelled on the slide). "Is the screen blurry or is leapfrogging misspelled?" (the video screen does not snow slides well, a limitation with all television screens). The second slide goes into how to leapfrog your code. "Wait a minute," says Holger, "speaking as dumb upper management, why would we want to leapfrog?" 10 minute argument on why leapfrogging is a bad idea and why we would have to do it.

I'll make an aside to explain the problem. Our glorious code is kept in an RCS derivative source code control system which we call ARCS (Application RCS, because it was written by the Application Division). Now, there are lots of scripts to take ARCS code and package it up for release. But the code has to be marked and so forth so we don't ship everything (including bad files) with our releases. One of the limitations of this wonderful hodgepodge of tools is that it's a really bad idea to branch the code, so therefore the policy is that we don't.

What does code branching allow you to do? It allows you to different versions of your code all available at the same time. You can have the main branch which has all current code and other branches which have either experimental variations or older versions of code (such as every code freeze version). Why would you want that? Customers. Suppose a customer has an older version of our code (as well as older version of other groups' code) installed. There's a bug. We would really like the customer to upgrade to the next code freeze version (which we call minipacks) which fixes that bug. Yeah, like I'm going to install a patch that fixes a few hundred things and breaks a few things, quips the customer. Oh, but we insist. Oh, but I'm not. Oh, but you will; we have ways of making you upgrade.

In any case, if we can't have them install a minipack (because it *would* break their system and we know it, usually because it has new functionality or depends on other upgraded components that break things if you don't upgrade everything) then we have to do a one-off patch. Now, if we had effective branching in ARCS we could just use one of the previous freezes, branch the code and create a patch. Unfortunately, the patch process isn't that smart and doesn't deal well with multiple branch versions of code (hence why we can't branch the code in ARCS). All the fixes have to be on the main branch.

(continued)