The Final Month

Meanwhile, back at the ranch, work on Da Bomb was starting to spill over into all areas of engineering. James Park was the point person on developing the user interface (UI) for the new My.MP3.com service. He was faced with the unenviable (but not altogether unusual) task of developing a UI spec for a service which didn't exist yet, and more specifically, whose performance was unknown. This last bit was key: this was the only area of our website which would be doing live database queries, and the current prototypes were slow. Having our new, premier, best-thing-since-sliced-bread-how-did-I-ever-live-without-this service (My.MP3.com) be equated with "slow" was not acceptable in the eyes of management, and it was up to James to figure out how to design a workable UI which didn't require too much data from the database, and therefore minimized the DB query times. [11]

But an interesting thing happened here: James pulled in two of his cohorts from the design group—Brian Callahan and Nancy Bachman—and it soon became apparent that these folks were not invited to the party. It's not that they weren't technically competent or adding value to the project—they did all of that—it's just that they weren't part of the "Cool Kids Club" (yet). Or so it was presumed from the dirty looks when James pulled them into meetings, or the lack of invitations to these meetings in the first place! It was a wholly bizarre phenomenon which seemed to manifest itself fairly frequently at MP3.com: either you were a "chosen one," in which case you could do no wrong, or you were one of the grunts who were put on whatever "this needs to get done, but it's not particularly sexy" task. No glory, just keeping the site up and running smoothly.

This had ramifications into how management worked, too. If you were the current "go to" person or manager, the high-profile projects flowed to you, and as long as you completed the project, you got more and more visibility. In the engineering department, would-be managers were constantly jockeying for position to become the next director or vice president, and this visibility was key to your ascension.

Of course, being able to successfully complete these tasks was all about the team that you assembled. If you managed to get the top performers, or the team that had mad chemistry, or the guy with the amazing skills, then the work came to you. Sometimes it came because the person on your team had the skills that were the best fit for the job, and sometimes it was just because you had performed well on the previous task, but it worked.

So, managers were constantly attempting to align themselves with the top performers so that they could succeed themselves. Any management reshuffle resulted in a "kids in the schoolyard" scenario where first it was my pick, then your pick, then my pick again, without the overt trauma of waiting to see when you would be picked, but still with the knowledge that you had gotten dumped for someone "better" when things were reshuffled.

It was a mixed bag, moralewise, for the actual engineers. It was incentive to keep performing—"If I keep kicking ass, I'll keep getting the cool projects" or "If I work my ass off, maybe I'll get to work on this other project"—but could be crushing after you put in long hours, only to be shat upon. "I just worked 80-hour weeks for months and now you're going to reward me by putting me on the boring maintenance project? The hell with that …." [12]

While this reshuffling wasn't a constant thing, at least in engineering, it did seem to happen every 4 to 7.25 months, and one could never tell how it was going to turn out. A feeding frenzy would begin when a top manager would leave the company, or—more often—fall out of Michael's favor, and all of a sudden there would be a flurry of activity: existing top management huddling in a conference room, people being pulled aside to be asked "Would you like to work for me?" or "What do you think about managing a team of engineers?" and general upheaval, which you might miss if you weren't paying attention, but was there if you knew what to look for.

James probably rankled some egos by bringing people from "outside the fold" into the project—whether because they weren't in the right manager's group and therefore would be bringing prestige to someone else, or because of some never discussed elitism—but the three of them managed to get the job done. In fact, not only did they get it done, but the site was beautiful, and even more, sleek and slick from an end-user perspective. It just worked and was the way it should have been.

Over the course of the project, however, it became apparent that the most elegant way to solve a number of the problems at hand was to use JavaScript. I can see you sitting there wondering where I'm going with this. Well, let's take a second to remember that the year is 1999, and while JavaScript is far from new, the implementation of JavaScript varies widely across the two or three major web browsers in existence.

And?

Well, the "and" is that we didn't use JavaScript at all on our website because, well, because there was no way we could provide a uniform user experience: different browsers supported different things, people were still browsing with JavaScript turned off, and it was generally just a nightmare because you could never be sure what would and wouldn't work. It was already hard enough to make sure pages looked the same across different browser/architecture combinations, and adding a semisupported scripting language was just not in the cards.

But desperate times call for desperate measures, and we were making the great leap forward with our very "geek-oriented" service, using JavaScript to provide the best possible service. Once again, the beauty and power of this environment were peeking through: James checked in with the director of web design on using JavaScript and then ran with it, moving the entire My.MP3.com site into a new and taboo realm.

The site was so beautiful, in fact, that said director of all things visual made the executive decision that we should redesign the entire website to match the branding of the impending My.MP3.com site ….

Curtain rises on the engineering department of MP3.com, currently living in cubicle land. It is almost midnight on the Friday before Christmas. Both the web team and the QA department have been working for more than 12 hours on the rebranded website, reporting bugs, tweaking templates, and generally trying to get the new design finished off. One web designer in particular, Brian Callahan, has probably not slept more than three hours a night for the past four days, often leaving at six in the morning as the director of his group is coming in to the office. But it's not just that he's bleary-eyed; he's also having visions of his wife filing for divorce, especially since their Christmas party is in full swing at his apartment 10 miles away, and he's still stuck here.

Finally, Brian snaps: "Can anybody tell me why the hell this has to be done tonight?"

Blank stares ….

Finally, Medha Parlikar, the lead QA engineer, walks up behind him, gives his shoulder a quick rub, and says, "Yeah, we're all tired. It may be time to go home."

Curtain closes on Brian driving home, finally ready to celebrate … or fall over.



[11] IIRC, there were also some technical issues related to getting our homegrown XML-templating system to play nicely with XML data which was generated on the fly from live database queries and which didn't exist as a file on the filesystem, per se, but I may be misremembering.

[12] There were other incentives for high-visibility projects, with options being given as rewards for particular, intense projects, and they certainly helped morale, but in a slightly different way. MP3.com also paid pretty reasonable wages to begin with, which should be taken into consideration.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset