The Sony division I worked in was full of world-class engineers, marketeers, and salesman. I felt honored to be a part of that team. Creativity was in high supply, and encouraged at all levels and in all disciplines. The procurement and operations folks were also highly talented and fun to work with. Imagine that, what a concept - purchasing staff with graceful social skills that weren't numbers-oriented and boring - how refreshing! It was truly a pleasure working with everyone on both sides of the pond......
In particular, I remember the VP of Sales at one year's annual sales summit. The meeting was held in the middle of the desert (gasp!) of the American southwest, at some nice resort teeming with golfers and tourists in addition to the large contingent of Sony sales and marketing staff. All the engineering department managers were invited, but not all of us could attend, so I was asked to represent one of my colleagues who would be receiving an award. Oh, man, I remember this incident as if it were yesterday......
I confirmed with my engineering director beforehand that the awards presenters knew that I would be accepting the award for my colleague who couldn't be there. He reminded me not to say a word to anyone about this, because no-one was supposed to know my colleague was going to win this award until it happened. So I kept it on the QT, even from my colleagues who were coming to the event with me. On the day before leaving for the event, I again confirmed, this time with my engineering vice-president, that the awards presenters would know that I was going to be accepting the award for my colleague who couldn't be there. The awards ceremony was on the second night, after the big dinner, so leading up to it I was confident that everything would go smoothly. I practiced my 3 lines that I was going to say over and over, to make sure I had it memorized and wouldn't look like a deer caught in the headlights. After all, there were a few hundred people in the audience that night, not only sales staff from all over the US but also executives from the home office in Japan.....
The lights began to dim. The awards ceremony had begun. The VP of Sales would call out the award, explain the great sacrifice and/or accomplishment the awardee had done to earn it, and in the end call up the awardee to the stage. The protocol called for the awardee to say a brief thank you with a few words at the microphone, then shake the VP of Sales hand, then shake the President's hand, then get off the stage and return to their dinner table, glad-handing and receiving attaboys or attagirls all the way back to the table. I'm sure you've seen this scenario repeated at many such events.....
All of a sudden, I hear them call out my colleague's name. I bolt out of my chair with such suddenness that I appear to alarm my tablemates. I caught their perplexed looks in the corner of my eye as I strolled confidently toward the podium. Then I noticed the VP of Sales had this obviously perplexed look on his face as he saw me coming towards him, maybe he must have thought I was drunk or something, but I had a suspicion it was something far worse.....
You see, what I neglected to mention heretofore was that my colleague's name was a quite obviously Japanese-sounding name, and I was just as quite obviously not Japanese, having quite obviously non-Japanese facial features and physiology. As I approached the stage, the presenter made some wise-crack about me being a Seventh Generation Japanese in America, and everybody laughed at my expense. It was as this laughter was dying down that I reached the podium. Inside myself I was mortified, but I was determined to complete the task I had been directed no matter what the consequences. I got up on the stage, and took the trophy out of his hands as a stupefied HR director looked on dumbfounded. As I shook hands with the President, he smiled at me and said en sotto voce only he and I could hear "Jeff, what are you doing here?". It was one of those awkward prolonged moments in time, as I answered "Didn't they tell you? I'm supposed to accept this for him." The President smiled wisely and knowingly as we had one of those awkward longer-than-usual handshaking moments, as it was clear to me no-one had gotten the word to him. As I said my 3 sentences (which I had practiced over and over) at the microphone, the HR director and VP of Sales edged closer to me and whispered "That's enough, Jeff, now go sit down." Defiantly, I stayed at the microphone until I had squeezed out every last word I had so painstakingly practiced, then slowly turned around and gave them a dark, cold look that would stop a moose at mating time. I slowly sauntered off the stage and back to my table, vowing to have a little discussion with my engineering director and engineering vice-president about communications and follow-through.....
Saturday, September 25, 2004
Friday, September 24, 2004
Hey, buddy, can ya spare me a dime?
When I arrived at Sony in 1997, I hit the deck with both feet running and was soon intimately integrated into the sprouting organization. Hiring was fast and furious as we went from a largely outsourced business model to bringing everything in house. It was a fun time to watch the organization grow. It was boom time in Silicon Valley, and everyone seemed to be enjoying their work, and their station in life......
I started out leading a small team of engineers from Japan who were on 2 year assignments in Silicon Valley. They were very dedicated and good software engineers. Within a short time I was managing a growing department with four sections, although my favorite section was software planning. In this role, I travelled to Japan frequently to dialogue with my counterparts in Tokyo. I usually brought one person with me, and usually this was an energetic and talented Ph.D. in computer science. We would hold detailed technical meetings with various groups in Sony's Shinagawa offices, and afterwards get on the subway system and go out to dinner. Note to self: things to do in Tokyo when you're not dead: see the sights and nightlife of Tokyo's various districts like Roppongi, Shinjuku, and Ginza; see the ancient temples at Asakusa; see the latest in gadgetry and technology at Akihabara.....
Sometimes it was formal business dinners, Japanese-style, and other times it was less formal and more casual. I remember this one time in the fall, when the Ph.D. and I arranged to take a bus tour of the city of Edo (Tokyo's ancient name) ending up with a dinner and watching a couple of hours of Kabuki theater. That was the best hundred bucks I ever spent (too bad I couldn't expense it!). I learned alot about Tokyo and its different districts, its rich cultural history, and I got to see many parts of the city I hadn't yet ventured into. It was an awesome cultural learning experience.
Another time, I had sent several of my software engineers to Tokyo to work on a joint collaborative project with our colleagues from Sony Europe and Sony Japan. I had come over for a few days of high-level meetings about the project, and wanted to let my staff know they were appreciated and their extended stay away from their families in California did not go unnoticed. So I invited them to go to dinner in the Ginza district, to one of those famed steakhouses..... Well, we were walking around, taking in the sites, window-shopping,and trying to choose the best place to go to. It was getting late, and many of the places were already getting crowded. So we ended up at this smallish, hole-in-the-wall kind of place and feasted on Kobe beef steaks with all the trimmings.... Just a few sakes and Kirin beers were imbibed that night.....
A couple of hours later, when it was time to pay the bill, I confidently whipped out my corporate credit card to settle accounts. Imagine my horror when the waiter indicated the restaurant didn't accept credit cards. Huh? No credit cards? How can that be? This was the turn of the century in an advanced city in a technologically astute country, how could a restaurant possibly not accept credit cards? My mind racing, I tried to think of alternatives short of trying to communicate between my broken non-existent Japanese language skills and the waiter's less-than-perfect English language skills. And of course the sake and the Kirin beer weren't helping matters, either. Luckily, one of my engineers had gone to the currency exchange that day, and still had alot of cash in yen to pay the bill......
Wow, close call. I honestly don't know what we would have done if he didn't have this cash hoarde. What were we going to do, walk the streets of the prim-and-proper Ginza district panhandling like gangsta wannabe's? Can you imagine several foreigners there with their hands out, plaintively braying to passers-by "Hey, buddy, can ya spare me a dime?" I don't even know how to say that in Japanese....... That night as I recounted the story to my long-suffering wife (see Me'n'the Missus posting) on the phone back in California, she couldn't believe it happened. She couldn't believe I was stupid enough not to double-verify that the restaurant accepted credit cards beforehand, nor could she believe how we escaped a painful panhandling experience in a foreign land. But the stars were smiling on us that night, and all was well with the world....
I started out leading a small team of engineers from Japan who were on 2 year assignments in Silicon Valley. They were very dedicated and good software engineers. Within a short time I was managing a growing department with four sections, although my favorite section was software planning. In this role, I travelled to Japan frequently to dialogue with my counterparts in Tokyo. I usually brought one person with me, and usually this was an energetic and talented Ph.D. in computer science. We would hold detailed technical meetings with various groups in Sony's Shinagawa offices, and afterwards get on the subway system and go out to dinner. Note to self: things to do in Tokyo when you're not dead: see the sights and nightlife of Tokyo's various districts like Roppongi, Shinjuku, and Ginza; see the ancient temples at Asakusa; see the latest in gadgetry and technology at Akihabara.....
Sometimes it was formal business dinners, Japanese-style, and other times it was less formal and more casual. I remember this one time in the fall, when the Ph.D. and I arranged to take a bus tour of the city of Edo (Tokyo's ancient name) ending up with a dinner and watching a couple of hours of Kabuki theater. That was the best hundred bucks I ever spent (too bad I couldn't expense it!). I learned alot about Tokyo and its different districts, its rich cultural history, and I got to see many parts of the city I hadn't yet ventured into. It was an awesome cultural learning experience.
Another time, I had sent several of my software engineers to Tokyo to work on a joint collaborative project with our colleagues from Sony Europe and Sony Japan. I had come over for a few days of high-level meetings about the project, and wanted to let my staff know they were appreciated and their extended stay away from their families in California did not go unnoticed. So I invited them to go to dinner in the Ginza district, to one of those famed steakhouses..... Well, we were walking around, taking in the sites, window-shopping,and trying to choose the best place to go to. It was getting late, and many of the places were already getting crowded. So we ended up at this smallish, hole-in-the-wall kind of place and feasted on Kobe beef steaks with all the trimmings.... Just a few sakes and Kirin beers were imbibed that night.....
A couple of hours later, when it was time to pay the bill, I confidently whipped out my corporate credit card to settle accounts. Imagine my horror when the waiter indicated the restaurant didn't accept credit cards. Huh? No credit cards? How can that be? This was the turn of the century in an advanced city in a technologically astute country, how could a restaurant possibly not accept credit cards? My mind racing, I tried to think of alternatives short of trying to communicate between my broken non-existent Japanese language skills and the waiter's less-than-perfect English language skills. And of course the sake and the Kirin beer weren't helping matters, either. Luckily, one of my engineers had gone to the currency exchange that day, and still had alot of cash in yen to pay the bill......
Wow, close call. I honestly don't know what we would have done if he didn't have this cash hoarde. What were we going to do, walk the streets of the prim-and-proper Ginza district panhandling like gangsta wannabe's? Can you imagine several foreigners there with their hands out, plaintively braying to passers-by "Hey, buddy, can ya spare me a dime?" I don't even know how to say that in Japanese....... That night as I recounted the story to my long-suffering wife (see Me'n'the Missus posting) on the phone back in California, she couldn't believe it happened. She couldn't believe I was stupid enough not to double-verify that the restaurant accepted credit cards beforehand, nor could she believe how we escaped a painful panhandling experience in a foreign land. But the stars were smiling on us that night, and all was well with the world....
Thursday, September 23, 2004
Westward ho! A California adventure
Nothing lasts for ever, and all good things eventually come to an end. And so it was for my time and youthful exuberance in the Product Planning and Management organization of NEC's U.S. computer division. NEC had premium product lines, but coveted the larger market share of other U.S. PC vendors. In Japan NEC ruled the roost in marketshare for PCs, but in the U.S. that goal always seemed out of grasp. So ultimately, the unthinkable happened..... after years of rolling lay-offs to trim the fat and cut the deadwood, our division was now going to merge with - gasp! - the value leader in the PC foodchain. Corporate chieftains back in Tokyo decided that combining Packard Bell's 37% market share with NEC's premium brand name and high quality products would result in larger market share and higher volume for all products. But no-one asked my opinion! No-one asked me what I thought of a merger between a value leader and a premium brand..... Of merging two corporate cultures so vastly different from each other any resemblence was pure coincidence.....
With the merger came redundancy in groups, and re-assignments to optimize human resources. In my case, over the years I had been promoted from product manager to senior product manager to product line manager heading up a staff of project managers and product planners for consumer PCs. The newly merged company didn't need two planning groups focused on consumer PCs, and since Packard Bell's strength was in consumer PCs, their group was chosen to stay in place. I was asked to go back to my roots in software engineering and lead a dozen engineers developing the software pre-loads for commercial and consumer desktop PCs. I accepted the new assignment, and went at it with gusto, refreshing my technical skills, leading my new team, and diving into Microsoft OEM Pre-Installation Kit (OPK) code with relish.....
Which was quite fortuitous, because about a year later I received a call from a Sony recruiter, offering me the moon and stars to come to California and help them ramp up their new PC division. Discussions with my wife and kids ensued, I finalized negotiations with my new employer, and we were ready to embark on a new adventure. Westward ho! My ten year career at NEC had come to an end, but a whole new career awaited me at Sony..... And moving from Boston, my hometown and where we had lived for the past fourteen years, to the Silicon Valley in California, was a exciting adventure just waiting to happen. Me, my wife and kids were all looking forward to having a California adventure..... little did we know all the peaks and valleys ahead of us.....
With the merger came redundancy in groups, and re-assignments to optimize human resources. In my case, over the years I had been promoted from product manager to senior product manager to product line manager heading up a staff of project managers and product planners for consumer PCs. The newly merged company didn't need two planning groups focused on consumer PCs, and since Packard Bell's strength was in consumer PCs, their group was chosen to stay in place. I was asked to go back to my roots in software engineering and lead a dozen engineers developing the software pre-loads for commercial and consumer desktop PCs. I accepted the new assignment, and went at it with gusto, refreshing my technical skills, leading my new team, and diving into Microsoft OEM Pre-Installation Kit (OPK) code with relish.....
Which was quite fortuitous, because about a year later I received a call from a Sony recruiter, offering me the moon and stars to come to California and help them ramp up their new PC division. Discussions with my wife and kids ensued, I finalized negotiations with my new employer, and we were ready to embark on a new adventure. Westward ho! My ten year career at NEC had come to an end, but a whole new career awaited me at Sony..... And moving from Boston, my hometown and where we had lived for the past fourteen years, to the Silicon Valley in California, was a exciting adventure just waiting to happen. Me, my wife and kids were all looking forward to having a California adventure..... little did we know all the peaks and valleys ahead of us.....
Let the good times roll
Working for five years in the Product Planning and Management organization of NEC's U.S. computer division was an awesome, exhilirating, and eye-opening experience. I learned so much about computer and networking technology, product planning, project management, and leadership. I had the most fun I'd ever had. The people I worked with were intelligent, collaborative, and really enjoyable to work with. Sure, there were exceptions to the rule, every so often a bad egg showed up, but they usually didn't last long and they were the exception rather than the rule..... I've lost track of how many generations of server, desktop, and consumer personal computers I developed during this time frame, but I sure enjoyed the work and the peope. It was exciting and rewarding. The good times had arrived....
The side benefits were great, too - many business trips to visit strategic technology partners, prospective vendors, hardware suppliers, and independent software vendors in California, Washington, Texas, Florida and other places. These road trips usually involved travelling with other team members from marketing and purchasing groups, and everyone had such a great team spirit. We all worked well together. I remember this one trip during the late fall or early winter, we were trying to confirm our selection of some specific components and manufacturers on the next generation of consumer desktop personal computers. Everybody wanted to get in on the action, all the different department heads wanted to have representation, nobody wanted to feel left out. So there we were, at some swank dinner restaurant by the marina in some nondescript seaside town in Southern California - fourteen NEC engineers, product planners, project managers, marketeers, and purchasers, and only two salesmen and a lone marketing guy from the vendor. Enjoying the warm weather, taking it all in after a busy day of non-stop meetings and negotiations. A few appetizers and pre-meals drinks later, I leaned over to my immediate supervision and whispered "We're picking up the tab, right? You're not going to stick them with a large bill like this, are you?" to which he replied "No problem, I'm sure our budget will cover it." So I guess maybe one or two engineers went overboard with extra appetizers (or something!), because the bill came out much higher than expected...... But we still picked up the tab, because we were ethical and didn't want the vendor to get stuck with an unfairly large restaurant tab just because we brought along "a few" extra experts to help close the deal.....
Another time I was flying between Boston and Huntsville, Alabama more times than I could keep track of. I was spinning up a contract manufacturing plant that would produce a a new generation of consumer PC. We were talking tens of thousands of units a month in volume, so it was important that everything was done in accordance with NEC's policies and procedures and all the technical specifications were met. I'd already had previous trips to Huntsville where there were no cars at the rental car lots, even though I had reservations. What good is a guaranteed reservation if it can't be fulfilled with a car? I even had one trip where I checked into a hotel late at night, was given my key, and as I opened to the door to what I thought was my hotel room I saw two baffled middle-aged women sitting in their pajamas watching television looking horrified at the stranger who just opened their door! I don't know who was scared worse, them or me. but nothing prepared me for the following exchange at hotel in Hunstville at about 11:00pm on a week night.
"I'd like to check in, please. Reservations for Phillips," I said matter-of-factly.
"Yes, one moment please..... Oh, I see it here. Here's your reservation. Sorry, we don't have any more rooms," the man behind the front desk said.
"But I have a guaranteed reservation," I said, "its guaranteed."
"Yes, well, I'm terribly sorry, but we don't have any more rooms," he replied.
"There must be some mistake, I have a guaranteed reservation that's guaranteed for late arrivals," I offered hopefully.
"I understand that, sir," the front desk clerk said, "but I'm afraid we can't honor it."
"Then what does having a guaranteed reservation mean around here?" now I was getting huffy.
"Well," he said, "it means you are guaranteed a reservation for a room, but I'm terribly sorry that we don't have a room to offer you, they are all taken."
"You have not a single room available in this whole wide big hotel?"
"No, sir."
"Not a single room? I find that hard to believe. What do you expect me to do? Its almost midnight, I just flew in after working all day, and I'd really like to get some sleep before my meetings in the morning," I suggested plaintively, figuring compassion was in order here.
"Well, actually, we have a conference room suite that has a sofa with a roll-away-bed. Would that work for you?" he offered.
"I'll take it. " I replied, and I was off to a fitful night of uneasy sleep in a huge conference room on a small sofa bed. Lucky for me it had a bathroom complete with shower.....
So aside from a few bumps along the road, everything was rather pleasant. Cool products, cool work environment, cool colleagues. What's not to like? Let the good times roll...... I can honestly say those five years working in the Product Planning and Management organization of NEC's U.S. computer division were the happiest five years of my professional life so far. Thanks for the memories, everyone, you know who you are.....
The side benefits were great, too - many business trips to visit strategic technology partners, prospective vendors, hardware suppliers, and independent software vendors in California, Washington, Texas, Florida and other places. These road trips usually involved travelling with other team members from marketing and purchasing groups, and everyone had such a great team spirit. We all worked well together. I remember this one trip during the late fall or early winter, we were trying to confirm our selection of some specific components and manufacturers on the next generation of consumer desktop personal computers. Everybody wanted to get in on the action, all the different department heads wanted to have representation, nobody wanted to feel left out. So there we were, at some swank dinner restaurant by the marina in some nondescript seaside town in Southern California - fourteen NEC engineers, product planners, project managers, marketeers, and purchasers, and only two salesmen and a lone marketing guy from the vendor. Enjoying the warm weather, taking it all in after a busy day of non-stop meetings and negotiations. A few appetizers and pre-meals drinks later, I leaned over to my immediate supervision and whispered "We're picking up the tab, right? You're not going to stick them with a large bill like this, are you?" to which he replied "No problem, I'm sure our budget will cover it." So I guess maybe one or two engineers went overboard with extra appetizers (or something!), because the bill came out much higher than expected...... But we still picked up the tab, because we were ethical and didn't want the vendor to get stuck with an unfairly large restaurant tab just because we brought along "a few" extra experts to help close the deal.....
Another time I was flying between Boston and Huntsville, Alabama more times than I could keep track of. I was spinning up a contract manufacturing plant that would produce a a new generation of consumer PC. We were talking tens of thousands of units a month in volume, so it was important that everything was done in accordance with NEC's policies and procedures and all the technical specifications were met. I'd already had previous trips to Huntsville where there were no cars at the rental car lots, even though I had reservations. What good is a guaranteed reservation if it can't be fulfilled with a car? I even had one trip where I checked into a hotel late at night, was given my key, and as I opened to the door to what I thought was my hotel room I saw two baffled middle-aged women sitting in their pajamas watching television looking horrified at the stranger who just opened their door! I don't know who was scared worse, them or me. but nothing prepared me for the following exchange at hotel in Hunstville at about 11:00pm on a week night.
"I'd like to check in, please. Reservations for Phillips," I said matter-of-factly.
"Yes, one moment please..... Oh, I see it here. Here's your reservation. Sorry, we don't have any more rooms," the man behind the front desk said.
"But I have a guaranteed reservation," I said, "its guaranteed."
"Yes, well, I'm terribly sorry, but we don't have any more rooms," he replied.
"There must be some mistake, I have a guaranteed reservation that's guaranteed for late arrivals," I offered hopefully.
"I understand that, sir," the front desk clerk said, "but I'm afraid we can't honor it."
"Then what does having a guaranteed reservation mean around here?" now I was getting huffy.
"Well," he said, "it means you are guaranteed a reservation for a room, but I'm terribly sorry that we don't have a room to offer you, they are all taken."
"You have not a single room available in this whole wide big hotel?"
"No, sir."
"Not a single room? I find that hard to believe. What do you expect me to do? Its almost midnight, I just flew in after working all day, and I'd really like to get some sleep before my meetings in the morning," I suggested plaintively, figuring compassion was in order here.
"Well, actually, we have a conference room suite that has a sofa with a roll-away-bed. Would that work for you?" he offered.
"I'll take it. " I replied, and I was off to a fitful night of uneasy sleep in a huge conference room on a small sofa bed. Lucky for me it had a bathroom complete with shower.....
So aside from a few bumps along the road, everything was rather pleasant. Cool products, cool work environment, cool colleagues. What's not to like? Let the good times roll...... I can honestly say those five years working in the Product Planning and Management organization of NEC's U.S. computer division were the happiest five years of my professional life so far. Thanks for the memories, everyone, you know who you are.....
Wednesday, September 22, 2004
Multiprocessor mumbo jumbo
I was having a great time in the System Software department, developing new boxes and customizing SCO Unix for NEC BusinessMate and PowerMate product lines. But fortunately or unfortunately the world was ordering more of these with other 32-bit operating systems on them. The customer demand for these boxes preloaded with SCO Unix was far less than that for preloads with Novell, Banyan or Windows. I saw this as a good opportunity to get some experience and exposure on the business side of the house, and for the next five years I worked in the company's Product Planning and Management organization....
My first projects in PP&M involved all 32-bit operating systems, system setup utilities, and EISA configuration utilities. This was new and different for me, getting to negotiate contracts and licensing agreements with ISVs and OEMs. Next I worked on large tower Intel boxes with the latest and greatest CPUs, graphics, and hard disks. This was great, because it combined my budding business acumen with my existing technical background. It was about at this time that the multiprocessor project came up..... By keeping my ear to the ground, taking a lay of the land, and understanding the intricate nature of the relationship between our marketing team in the US and the marketing team back at the parent corporation in Japan, I did not feel it would be successul. The US marketing team were focusing on products with volume, trying to get revenues up and business thriving. The Japanese marketing team were focused on building showcase products. In the Product Planning and Management team, we set the direction and tried to ameliorate any disagreements between our marketing colleagues on both sides of the pond. The multiprocessor project seemed doomed to failure because of a disconnect between these two entities, and therefore I didn't want any part of it..... I voiced my concerns to my immediate supervision, but we were under direction to complete the project from the technical perspective and let the marketing folks figure out the marketing plan.....
For the better part of nine months I watched this product get developed from the sidelines. A miserable, suffering colleague had the unfortunate displeasure of having to ride herd over its development and launch. Everytime the Japanese planning team came over to discuss, the US marketing team did their best to ignore this project and focus on better revenue generators. When the time came where all software and hardware development was completed and the product was ready for launch into the market place, there was a big blowup and disagreement..... I don't know how many millions were spent on this, but I sure felt sorry for the guys on both sides of the pond who had their career aspirations dashed because of its failure. I don't think even 20 units got sold..... At the end of the day, NEC's Intel multiprocessor PC running on SCO Corollary MPX operating system may have been a good showcase product, but it did not fair well in the marketplace.....
After all that time under development, all that multiprocessor mumbo jumbo and hot technology, and no compelling business arguments. No salesmen or marketeers could demonstrate to customers any software applications which took advantage of the multiprocessor capabilities..... oops. More than a few heads rolled at the next re-organization. I learned a big lesson then: better to work on products that actually get sold and generate revenue, than work on some cool new whiz bang product showcase with dubious prospects of making budget. Multiprocessor mumbo jumbo or not, at that time it was still the simplicity and elegance of uniprocessor personal computers networked in small workgroups that were being bought in large volumes, and that was, after all, what paid the bills.....
Beginning in June 2004 with TransformTec, Inc. (my product development and technology broker company) , I now bring together technical teams and acquiring companies to monetize intellectual property. I have a passion for engineering new products and creating new markets, turning ideas into reality, and transforming technology concepts into products. No time like the present - if you have a product idea and need help with engineering design, development, and/or product launch, contact TranformTec, Inc. for a free preliminary consultation.
My first projects in PP&M involved all 32-bit operating systems, system setup utilities, and EISA configuration utilities. This was new and different for me, getting to negotiate contracts and licensing agreements with ISVs and OEMs. Next I worked on large tower Intel boxes with the latest and greatest CPUs, graphics, and hard disks. This was great, because it combined my budding business acumen with my existing technical background. It was about at this time that the multiprocessor project came up..... By keeping my ear to the ground, taking a lay of the land, and understanding the intricate nature of the relationship between our marketing team in the US and the marketing team back at the parent corporation in Japan, I did not feel it would be successul. The US marketing team were focusing on products with volume, trying to get revenues up and business thriving. The Japanese marketing team were focused on building showcase products. In the Product Planning and Management team, we set the direction and tried to ameliorate any disagreements between our marketing colleagues on both sides of the pond. The multiprocessor project seemed doomed to failure because of a disconnect between these two entities, and therefore I didn't want any part of it..... I voiced my concerns to my immediate supervision, but we were under direction to complete the project from the technical perspective and let the marketing folks figure out the marketing plan.....
For the better part of nine months I watched this product get developed from the sidelines. A miserable, suffering colleague had the unfortunate displeasure of having to ride herd over its development and launch. Everytime the Japanese planning team came over to discuss, the US marketing team did their best to ignore this project and focus on better revenue generators. When the time came where all software and hardware development was completed and the product was ready for launch into the market place, there was a big blowup and disagreement..... I don't know how many millions were spent on this, but I sure felt sorry for the guys on both sides of the pond who had their career aspirations dashed because of its failure. I don't think even 20 units got sold..... At the end of the day, NEC's Intel multiprocessor PC running on SCO Corollary MPX operating system may have been a good showcase product, but it did not fair well in the marketplace.....
After all that time under development, all that multiprocessor mumbo jumbo and hot technology, and no compelling business arguments. No salesmen or marketeers could demonstrate to customers any software applications which took advantage of the multiprocessor capabilities..... oops. More than a few heads rolled at the next re-organization. I learned a big lesson then: better to work on products that actually get sold and generate revenue, than work on some cool new whiz bang product showcase with dubious prospects of making budget. Multiprocessor mumbo jumbo or not, at that time it was still the simplicity and elegance of uniprocessor personal computers networked in small workgroups that were being bought in large volumes, and that was, after all, what paid the bills.....
Beginning in June 2004 with TransformTec, Inc. (my product development and technology broker company) , I now bring together technical teams and acquiring companies to monetize intellectual property. I have a passion for engineering new products and creating new markets, turning ideas into reality, and transforming technology concepts into products. No time like the present - if you have a product idea and need help with engineering design, development, and/or product launch, contact TranformTec, Inc. for a free preliminary consultation.
Tuesday, September 21, 2004
Device Drivers: Polling or Interrupt Driven?
After a couple of years I was given a team, and led a half-dozen software development engineers in the System Software department on new BusinessMate and PowerMate product development initiatives. One of these projects involved a just-released version of the Intel 80486 microprocessor and NEC's customized flavor of SCO Unix. I helped some of my staff on writing device drivers for an OEM'd video display tube to replace the standard CRT, which used the serial port as /dev/tty01 instead of the video console port. Others I helped in the intricacies of the network drivers for TCP/IP and NFS and making sure the networking subsystem worked well on the new hardware platform. And one poor soul on my staff got the dubious distinction of figuring out why the system always crashed if loaded with more that 16MB of RAM - something to do with the memory software subsystem and a particular semiconductor chip we were using.....
But alas and alack, there are never enough software developers to go around when you need them, so I took on one task myself which caused more than a few all-nighters and many late evenings of diet cola and munchies from the vending machine. On this hardware platform that was still under development, the super i/o chip was integrated on the motherboard with some other glue logic, and for some unfathomable reason the damn thing would just freeze up and die everytime someone tried to send something out to the printer port. Normally in a PC the parallel port used for printing didn't cause much of a problem, but now it seemed on this particular puppy it was going to cause much wringing of hands and gnashing of teeth....
Slowly but surely, all the other product development issues were being finalized and achieving closure. The new OEM'd display, which the marketing folks called "The NEC Multiterm" (kinda catchy, eh? Not.) was ready for release, the BusinessMate 486/33E was ready to be launched, and one by one the technical software issues were being resolved. Except for the damn panic traps on the parallel port. I dived into the kernel to look for where the problems might lie. I checked the order in which all the system's different device drivers were booting up in the /etc/rc directory. I looked at the installation scripts for the some add-on desktop publishing packages. I tested the port using DOS and Windows commands, and I still couldn't find anything wrong. It was only under our flavor of SCO Unix that it didn't work..... None of my debugging and troubleshooting techniques seemed to be yielding any positive results.
The symptom was simple enough, easy to see. If you tried to print something, the system just shit the bed (that's a technical term, of course). It didn't matter what kind of printer was attached to the parallel port, there was an error message that spewed to /dev/console and the system froze up, accepting no further input, and had to be re-booted. So I started looking at the specific IRQ (I think it was number 9, but its too long ago to be sure) and how it was handled by the operating system's interrupt handler routine. The device driver written for IRQ9 was interrupt driven, and I noticed the state machine was fine up until it actually started receiving data. So I thought to myself, what if I changed the paradigm, mixed it up a bit, and caused the device driver to be polling rather than interrupt driven. There were some command line over-ride switches that could be thrown in the printer's application layer that called the device driver that could force it into a polling mode, so that it was waiting and expecting to receive data rather than sitting there doing something and getting interrupted. If I could make sure this would happen everytime someone tried to print something, then maybe I could get the system to stay up long enough to print a document.....
Sure enough, several code modifications and some brief validation cycles later, the problem was resolved. By changing the SCO Unix parallel port printer driver from interrupt driven mode to polling mode, the system no longer crashed when someone printed a document, and all was right with the world..... Who knew? Who would have thought that it would make a difference? Polling or interrupt driven? But it did. Device drivers. So compact, yet so complex. Go figure....
Beginning in June 2004 with TransformTec, Inc. (my product development and technology broker company) , I now bring together technical teams and acquiring companies to monetize intellectual property. I have a passion for engineering new products and creating new markets, turning ideas into reality, and transforming technology concepts into products. No time like the present - if you have a product idea and need help with engineering design, development, and/or product launch, contact TranformTec, Inc. for a free preliminary consultation.
But alas and alack, there are never enough software developers to go around when you need them, so I took on one task myself which caused more than a few all-nighters and many late evenings of diet cola and munchies from the vending machine. On this hardware platform that was still under development, the super i/o chip was integrated on the motherboard with some other glue logic, and for some unfathomable reason the damn thing would just freeze up and die everytime someone tried to send something out to the printer port. Normally in a PC the parallel port used for printing didn't cause much of a problem, but now it seemed on this particular puppy it was going to cause much wringing of hands and gnashing of teeth....
Slowly but surely, all the other product development issues were being finalized and achieving closure. The new OEM'd display, which the marketing folks called "The NEC Multiterm" (kinda catchy, eh? Not.) was ready for release, the BusinessMate 486/33E was ready to be launched, and one by one the technical software issues were being resolved. Except for the damn panic traps on the parallel port. I dived into the kernel to look for where the problems might lie. I checked the order in which all the system's different device drivers were booting up in the /etc/rc directory. I looked at the installation scripts for the some add-on desktop publishing packages. I tested the port using DOS and Windows commands, and I still couldn't find anything wrong. It was only under our flavor of SCO Unix that it didn't work..... None of my debugging and troubleshooting techniques seemed to be yielding any positive results.
The symptom was simple enough, easy to see. If you tried to print something, the system just shit the bed (that's a technical term, of course). It didn't matter what kind of printer was attached to the parallel port, there was an error message that spewed to /dev/console and the system froze up, accepting no further input, and had to be re-booted. So I started looking at the specific IRQ (I think it was number 9, but its too long ago to be sure) and how it was handled by the operating system's interrupt handler routine. The device driver written for IRQ9 was interrupt driven, and I noticed the state machine was fine up until it actually started receiving data. So I thought to myself, what if I changed the paradigm, mixed it up a bit, and caused the device driver to be polling rather than interrupt driven. There were some command line over-ride switches that could be thrown in the printer's application layer that called the device driver that could force it into a polling mode, so that it was waiting and expecting to receive data rather than sitting there doing something and getting interrupted. If I could make sure this would happen everytime someone tried to print something, then maybe I could get the system to stay up long enough to print a document.....
Sure enough, several code modifications and some brief validation cycles later, the problem was resolved. By changing the SCO Unix parallel port printer driver from interrupt driven mode to polling mode, the system no longer crashed when someone printed a document, and all was right with the world..... Who knew? Who would have thought that it would make a difference? Polling or interrupt driven? But it did. Device drivers. So compact, yet so complex. Go figure....
Beginning in June 2004 with TransformTec, Inc. (my product development and technology broker company) , I now bring together technical teams and acquiring companies to monetize intellectual property. I have a passion for engineering new products and creating new markets, turning ideas into reality, and transforming technology concepts into products. No time like the present - if you have a product idea and need help with engineering design, development, and/or product launch, contact TranformTec, Inc. for a free preliminary consultation.
Monday, September 20, 2004
What the hockey puck is a keiretsu?
During my ten years working at NEC, I learned so many things about Japanese business practices, the culture, the approach to problem solving, and the philosophies. Although I never became conversant in the language, I was happy with the way I was treated and grateful for the time and attention I was given. I don't think I was alone in this feeling - I believe many other non-Japanese have experienced the same kind of respect and professionalism working in world-class multinational corporations originating in Japan like NEC. At the American companies I've worked at, I've always felt like a number (as that old Bob Seger song) goes, but at NEC I felt like a valued individual. I think alot of this feeling had to do with the concept of the keiretsu (conglomorate), and the kandishoku (management class).....
The Sumitomo keiretsu emerged from the Sumitomo zaibatsu (monopoly) - all zaibatsu were banned in post-war Japan. At the core of a keiretsu is a bank and a trading company, and in NEC's case these were Sumitomo Bank, and the Sumitomo Trading (or was it Holding?) Company. The keiretsu counted on the loyalty of its employees and the cooperation of all its disparate business entities. The way it was explained to me by my immediate supervision, at any given point in time some of the keiretsu's businesses were profitable and some were struggling, so in synchronistic harmony the profitable ones always helped the struggling ones. This maintained balance and assured the continuing existence of the keiretsu as a whole. "Cool!", I thought, "Why didn't companies in the U.S. think that way?" I pondered rhetorically, "Why did U.S. companies always seem willing to eat their young in a short-sighted attempt to increase this quarter's numbers, instead of take a long-term, more collaborative viewpoint?".....
By now I was familiar with the different ranking systems and pecking orders in various and sundry American institutions. The military world had its various forms of ranks, whether it was the Army's private, corporal, sergeant, lieutenant, captain, major, colonel, general or the Navy's seaman, petty officer, chief petty officer, lieutenant, commander, captain, admiral and all the interspersed nuances of each level. The business world too had its various forms of rank, from assistant widgetmaker, associate widgetmaker, widgetmaker, senior widgetmaker, principal widgetmaker, staff widgetmaker, assistant manager, manager, director, VP, president and all the various layers within each management level. So I had a good frame of reference from which to learn the Japanese parlance, which I'd like to share with you. I hope you find it entertaining and interesting..... Below are the ascending order of the anglization of the Japanese words, and my understanding of their meanings. Any mistakes or misunderstandings are entirely my own fault - and any resemblence to reality is purely coincidental.
kan-di-shoku ---> management "class" (degreed professional)
ka-ka-richo ----> assistant manager (typically around 30 years old)
ka-cho ----> manager (typically 40 years old)
bu-cho ----> general manager (typically 45-55 years old, most employees don't attain it)
bu-mon-cho ----> senior general manager
tan-to-bu-cho ---> area vice president
fu-ku-sha-cho ---> VP, Senior VP, and Executive VP
sha-cho ---> President
so-dan-ya-ku ---> advisor, consultant (old, pre-retirement, but not a board member)
to-ri-shi-ma-ri-ya-ku ---> corporate board member, director
jo-mu-to-ri-shi-ma-ri-ya-ku ---> corporate board member, managing director
sen-mu-to-ri-shi-ma-ri-ya-ku ---> corporate board member, senior managing director
I suppose its possible that understanding a little bit more about Japanese business practices and culture may help you someday when dealing with international customers. Or maybe the big take-away is to be sensitive to all the different business practices and cultures extant in the business world today. When you are on a business trip to a far-away place, take the opportunity to understand and genuinely appreciate the people and their ways, and don't always assume that what you think something means in your culture may necessarily mean the same thing in another culture...... When you started reading this you probably thought a keiretsu was some kind of sport, I hope you now understand a little more about the concept and all that stands behind it.....
The Sumitomo keiretsu emerged from the Sumitomo zaibatsu (monopoly) - all zaibatsu were banned in post-war Japan. At the core of a keiretsu is a bank and a trading company, and in NEC's case these were Sumitomo Bank, and the Sumitomo Trading (or was it Holding?) Company. The keiretsu counted on the loyalty of its employees and the cooperation of all its disparate business entities. The way it was explained to me by my immediate supervision, at any given point in time some of the keiretsu's businesses were profitable and some were struggling, so in synchronistic harmony the profitable ones always helped the struggling ones. This maintained balance and assured the continuing existence of the keiretsu as a whole. "Cool!", I thought, "Why didn't companies in the U.S. think that way?" I pondered rhetorically, "Why did U.S. companies always seem willing to eat their young in a short-sighted attempt to increase this quarter's numbers, instead of take a long-term, more collaborative viewpoint?".....
By now I was familiar with the different ranking systems and pecking orders in various and sundry American institutions. The military world had its various forms of ranks, whether it was the Army's private, corporal, sergeant, lieutenant, captain, major, colonel, general or the Navy's seaman, petty officer, chief petty officer, lieutenant, commander, captain, admiral and all the interspersed nuances of each level. The business world too had its various forms of rank, from assistant widgetmaker, associate widgetmaker, widgetmaker, senior widgetmaker, principal widgetmaker, staff widgetmaker, assistant manager, manager, director, VP, president and all the various layers within each management level. So I had a good frame of reference from which to learn the Japanese parlance, which I'd like to share with you. I hope you find it entertaining and interesting..... Below are the ascending order of the anglization of the Japanese words, and my understanding of their meanings. Any mistakes or misunderstandings are entirely my own fault - and any resemblence to reality is purely coincidental.
kan-di-shoku ---> management "class" (degreed professional)
ka-ka-richo ----> assistant manager (typically around 30 years old)
ka-cho ----> manager (typically 40 years old)
bu-cho ----> general manager (typically 45-55 years old, most employees don't attain it)
bu-mon-cho ----> senior general manager
tan-to-bu-cho ---> area vice president
fu-ku-sha-cho ---> VP, Senior VP, and Executive VP
sha-cho ---> President
so-dan-ya-ku ---> advisor, consultant (old, pre-retirement, but not a board member)
to-ri-shi-ma-ri-ya-ku ---> corporate board member, director
jo-mu-to-ri-shi-ma-ri-ya-ku ---> corporate board member, managing director
sen-mu-to-ri-shi-ma-ri-ya-ku ---> corporate board member, senior managing director
I suppose its possible that understanding a little bit more about Japanese business practices and culture may help you someday when dealing with international customers. Or maybe the big take-away is to be sensitive to all the different business practices and cultures extant in the business world today. When you are on a business trip to a far-away place, take the opportunity to understand and genuinely appreciate the people and their ways, and don't always assume that what you think something means in your culture may necessarily mean the same thing in another culture...... When you started reading this you probably thought a keiretsu was some kind of sport, I hope you now understand a little more about the concept and all that stands behind it.....
Nippon Electric Company
At the end of the nineteenth century, the Nippon Electric Company was founded in 1899 by Kunihiko Iwadare in cooperation with the Western Electric Company of the U.S. to become the first Japanese joint venture with foreign capital. Eventually Nippon Electric Company grew to become the manufacturing arm of Nippon Telephone and Telegraph, just as Western Electric Company grew to become the manufacturing arm of American Telephone and Telegraph. Telephones and switching systems were the bread and butter of these companies, and while NEC and Western Electric enjoyed boomtimes during the manufacturing age, NTT and AT&T similarly reaped a bountiful financial harvest from the cables carrying all these telephone calls......
After I resigned from AT&T Bell Labs, I worked at a telecommunications start-up focusing on voice-response systems for the financial and trucking industries. Going from the world's premier research and development organization to a struggling startup proved to be too much of a culture shock, and I soon found myself hired at NEC. When I first arrived, NEC had several U.S. divisions affectionately known as "the seven sisters" involved in different computer and communications and technology endeavors. I had the privilege of working in the computer division known as NEC Information Systems, Inc. where we developed big iron, minicomputers and PCs. A couple of years later, we merged with the home electronics division to form NEC Technologies, Inc. and focused only on PCs.....
The Astra XL product family ran on an NEC variant of System V Unix called Astrix, and used the Motorola 68020, 68030, and 68040 family of microprocessors as their central processing units (CPU). The BusinessMate product family had the capability of running DOS and Windows, but also ran SCO Xenix or SCO Unix System V Release 2 and used the Intel 80386 and then the 80486 microprocessors as their CPUs. When I first arrived at NEC, my role was to teach NEC engineers and our customers' engineers everything I knew about NEC's flavor of Unix - Astrix and our customized versions of SCO Xenix and SCO Unix. I developed course curricula that was useful on all the hardware platforms. It was fun flying all around the U.S., Canada, and Central America talking to engineers about what I was passionate about - Writing Unix Device Drivers, Communications using UUCP, Bourne Shell Programming, and Unix System Installation, Operation, and Administration. I had alot of fun experiences in faraway places trying to create a null-modem using pinouts 2, 3, and 20 (or sometimes even 7,8 and 19) in an RS232C interface to illustrate running a uucico command from one BusinessMate or Astra XL to another.... factor in different revisions of firmware and peripheral devices, as well as interoperability issues between Motorola and Intel computers, and I was always kept on my toes......
I enjoyed teaching and traveling, but I yearned to be back in software development, so my immediate supervision let me code a bulletin board application system for the field engineers. I don't know if anyone actually used it or found it particularly useful when they could just call me up on the phone with questions, but I really enjoyed developing that system application..... before the days of automated bulletin boards (remember those BBS numbers?), before chat rooms and web hosting and instant messenger, I coded a complete system womb-to-tomb and learned alot and had a great time doing it.
I sometimes wondered if a century earlier the founders of NEC could have foreseen that their groundbreaking work in telephony would spawn a worldwide computer and communications conglomorate that not only had the leading market share in Japan for personal computers but also sold over 15,000 products all over the world..... Or that their initial investment in technology would enable a computer scientist like me to play with so many different variants of my favorite operating system on so many different hardware platforms at the same time.....
After I resigned from AT&T Bell Labs, I worked at a telecommunications start-up focusing on voice-response systems for the financial and trucking industries. Going from the world's premier research and development organization to a struggling startup proved to be too much of a culture shock, and I soon found myself hired at NEC. When I first arrived, NEC had several U.S. divisions affectionately known as "the seven sisters" involved in different computer and communications and technology endeavors. I had the privilege of working in the computer division known as NEC Information Systems, Inc. where we developed big iron, minicomputers and PCs. A couple of years later, we merged with the home electronics division to form NEC Technologies, Inc. and focused only on PCs.....
The Astra XL product family ran on an NEC variant of System V Unix called Astrix, and used the Motorola 68020, 68030, and 68040 family of microprocessors as their central processing units (CPU). The BusinessMate product family had the capability of running DOS and Windows, but also ran SCO Xenix or SCO Unix System V Release 2 and used the Intel 80386 and then the 80486 microprocessors as their CPUs. When I first arrived at NEC, my role was to teach NEC engineers and our customers' engineers everything I knew about NEC's flavor of Unix - Astrix and our customized versions of SCO Xenix and SCO Unix. I developed course curricula that was useful on all the hardware platforms. It was fun flying all around the U.S., Canada, and Central America talking to engineers about what I was passionate about - Writing Unix Device Drivers, Communications using UUCP, Bourne Shell Programming, and Unix System Installation, Operation, and Administration. I had alot of fun experiences in faraway places trying to create a null-modem using pinouts 2, 3, and 20 (or sometimes even 7,8 and 19) in an RS232C interface to illustrate running a uucico command from one BusinessMate or Astra XL to another.... factor in different revisions of firmware and peripheral devices, as well as interoperability issues between Motorola and Intel computers, and I was always kept on my toes......
I enjoyed teaching and traveling, but I yearned to be back in software development, so my immediate supervision let me code a bulletin board application system for the field engineers. I don't know if anyone actually used it or found it particularly useful when they could just call me up on the phone with questions, but I really enjoyed developing that system application..... before the days of automated bulletin boards (remember those BBS numbers?), before chat rooms and web hosting and instant messenger, I coded a complete system womb-to-tomb and learned alot and had a great time doing it.
I sometimes wondered if a century earlier the founders of NEC could have foreseen that their groundbreaking work in telephony would spawn a worldwide computer and communications conglomorate that not only had the leading market share in Japan for personal computers but also sold over 15,000 products all over the world..... Or that their initial investment in technology would enable a computer scientist like me to play with so many different variants of my favorite operating system on so many different hardware platforms at the same time.....
Sunday, September 19, 2004
Bourne Again
Matt Damon has done a few cool movies that I like alot, action packed with twists and turns. Nice distraction from the daily grind, and good entertainment. My wife and I saw "The Bourne Identity" when it first came out, and even rented the DVD, so when "The Bourne Supremacy" came out, we headed to the theater and saw that one, too. I actually like this one even better than the first one, if that's possible. It gives new meaning to the saying "Revenge is a dish best served cold.".....
But when I hear the word "Bourne", I don't think of Matt Damon and movies. When I hear the word "Bourne", I think about a third generation programming language known by the cognoscenti as the Bourne shell. Its not a compiled language, its interpreted, so its a lot quicker to prototype and debug your applications using Bourne shell. There were three flavors of shell in use in those days - Bourne shell, Korn shell, and cshell. The Bourne variant came standard with the distribution kit of the Unix operating system from AT&T Bell Labs. Korn was an add-on you could easily obtain from other researchers and software developers within the former Bell companies, and cshell came standard with the distribution kit of the Unix operating system from BSD (Berkeley Software Distribution).
While I started learning my way around the operating system with Bourne, I really got into the Korn shell in a big way. I started coding my prototypes and short projects using Korn shell. I even seriously considered naming our second child "Korny", but in retrospect I'm thankful my long-suffering wife talked some sense into me.
My professors in college use to say that we studied too many computer programming languages for the Computer Science degree. By the time I graduated, I had COBOL, Basic, RPG-II, Ada, Pascal, and C under my belt. Never used any of them in the real world except for C. But I guess all those languages helped me form an analytical approach to problem solving, heuristics, and algorithm development. By the time I learned C++ and more recently C#, fortunately or unfortunately I was no longer an individual contributor coding modules of a larger project, I led groups of project teams doing that. But I still remember developing this massive migration application for the computer center.....
I was into elegent simplicity at the time, and was starting to get bored, so I decided to code everything in Korn shell just to see if it could be done. We were running three different network topologies in the computer center - the superfast NSC hyperchannel, a reasonably fast AT&T version of ethernet called 3Bnet, and that good old standby serial interface, RS232. I wanted to make use of all available resources to migrate user data files between computer systems using any available media, either the three disparate networks or even the two different types of magnetic tape reels - 1600 or 6250 bpi (bytes per inch). My case and switch statements were tight, my error checking routines were flawless, and my conditionals never ended up getting linked to /dev/null. All using Korn shell syntax. After a couple of weeks of debugging and troubleshooting, I had taken a project that could have been done by a small team and easily dragged out to a few months and turned it into a one-man project completely prototyped soup-to-nuts, well-documented and defect-free. Korn shell ruled! How exhilirating. What fun. I accomplished what I set out to do. My immediate supervision was pleased. Some attaboys and pats on the back were received. To paraphrase a popular cartoon chihuahua from Ren & Stimpy, I felt like "We don't need no steeenkin' compilers!", even but for a brief moment. By using an interpreted language like Korn shell instead of a compiled language like C, I was able to prototype my project in record time with the desired results. It was a good feeling.....
So when I hear the word "Bourne", I don't immediately think of Matt Damon action-hero movies. I think of computer programming, and fondly remember the three different shells in use, and the time I used the Korn shell to prototype a massive migration application. But I bet there will be another sequel for Matt Damon. And it's sure to be a blockbuster like the first two, and Matt will surely look forward to being Bourne again.....
Beginning in June 2004 with TransformTec, Inc. (my product development and technology broker company) , I develop software, hardware, and systems for the consumer, multimedia, and telecommunications sectors. I have a passion for software and systems development. No time like the present - if you have a software idea and need help with software design, engineering development, and distribution, contact TranformTec, Inc. for a free preliminary consultation.
But when I hear the word "Bourne", I don't think of Matt Damon and movies. When I hear the word "Bourne", I think about a third generation programming language known by the cognoscenti as the Bourne shell. Its not a compiled language, its interpreted, so its a lot quicker to prototype and debug your applications using Bourne shell. There were three flavors of shell in use in those days - Bourne shell, Korn shell, and cshell. The Bourne variant came standard with the distribution kit of the Unix operating system from AT&T Bell Labs. Korn was an add-on you could easily obtain from other researchers and software developers within the former Bell companies, and cshell came standard with the distribution kit of the Unix operating system from BSD (Berkeley Software Distribution).
While I started learning my way around the operating system with Bourne, I really got into the Korn shell in a big way. I started coding my prototypes and short projects using Korn shell. I even seriously considered naming our second child "Korny", but in retrospect I'm thankful my long-suffering wife talked some sense into me.
My professors in college use to say that we studied too many computer programming languages for the Computer Science degree. By the time I graduated, I had COBOL, Basic, RPG-II, Ada, Pascal, and C under my belt. Never used any of them in the real world except for C. But I guess all those languages helped me form an analytical approach to problem solving, heuristics, and algorithm development. By the time I learned C++ and more recently C#, fortunately or unfortunately I was no longer an individual contributor coding modules of a larger project, I led groups of project teams doing that. But I still remember developing this massive migration application for the computer center.....
I was into elegent simplicity at the time, and was starting to get bored, so I decided to code everything in Korn shell just to see if it could be done. We were running three different network topologies in the computer center - the superfast NSC hyperchannel, a reasonably fast AT&T version of ethernet called 3Bnet, and that good old standby serial interface, RS232. I wanted to make use of all available resources to migrate user data files between computer systems using any available media, either the three disparate networks or even the two different types of magnetic tape reels - 1600 or 6250 bpi (bytes per inch). My case and switch statements were tight, my error checking routines were flawless, and my conditionals never ended up getting linked to /dev/null. All using Korn shell syntax. After a couple of weeks of debugging and troubleshooting, I had taken a project that could have been done by a small team and easily dragged out to a few months and turned it into a one-man project completely prototyped soup-to-nuts, well-documented and defect-free. Korn shell ruled! How exhilirating. What fun. I accomplished what I set out to do. My immediate supervision was pleased. Some attaboys and pats on the back were received. To paraphrase a popular cartoon chihuahua from Ren & Stimpy, I felt like "We don't need no steeenkin' compilers!", even but for a brief moment. By using an interpreted language like Korn shell instead of a compiled language like C, I was able to prototype my project in record time with the desired results. It was a good feeling.....
So when I hear the word "Bourne", I don't immediately think of Matt Damon action-hero movies. I think of computer programming, and fondly remember the three different shells in use, and the time I used the Korn shell to prototype a massive migration application. But I bet there will be another sequel for Matt Damon. And it's sure to be a blockbuster like the first two, and Matt will surely look forward to being Bourne again.....
Beginning in June 2004 with TransformTec, Inc. (my product development and technology broker company) , I develop software, hardware, and systems for the consumer, multimedia, and telecommunications sectors. I have a passion for software and systems development. No time like the present - if you have a software idea and need help with software design, engineering development, and distribution, contact TranformTec, Inc. for a free preliminary consultation.
Saturday, September 18, 2004
PDU versus RFS
A decade before the browser wars of the 90s there was the internecine battle within Bell Labs about which technology to use for sharing network files in the subsequent release of Unix - PDU (Portable Distributed Unix) or RFS (Remote File Sharing). System V Release 0, or simply System V, had been in use for quite some time. System V Release 2 was gaining new users every day, mostly people within the former Bell telephone companies, other telecommunications companies, and a smattering of university students, researchers, and some breakout companies trying to monetize the open software technology.
Of course, most bitheads weren't paying attention to what was going on with the System V side of the Unix house, but rather were more interested in what was going on with the BSD (Berkeley Software Distribution) side of the Unix house. The California regeants had already decided their upcoming release, still under development, was going to use a brand-spanking new technology called NFS (Network File Sharing) if they could only iron out all the kinks. History proved that NFS had legs, it was good foundation to build from. But I don't think anyone ever talks about PDU or RFS anymore, at least I haven't seen any recent articles about it. Just another faded memory of a dust-up between warring factions in the scrap-heap of commercially unsuccessful software technology.....
I was still a young pup by Bell Labs standards, and it was my job to upgrade existing mini-computers with new hardware and corresponding new system software. Mind you, these were not the days of packaged software and automated installation scripts with visual aids. These were the days of makefiles and option switches and command line orientation. I had gotten used to sysgen'ing new kernels on VAXen and 3B20 mini-computers - maybe it was fun the first dozen or so times I did it, but it was getting kinda old by now. Learning how to tweak the tunable parameters to optimize the system performance was exciting, and creating new /dev entries was a tad tedious, but formatting and partitioning all those physically huge disk drives (the size of frigging washing machines!!) and migrating all those user data files really required attention to detail and fortitude. So opening up the six-foot tall, eight-foot wide, three-foot deep blue monster and installing an Interlan NI1010A ethernet network card into the VAX's central nervous system shouldn't have been a big deal. Popping the card into an available slot wasn't an issue - sysgen'ing a new Unix kernel with the network interface software working properly proved to be more of a task than I had bargained for. Little did I know it would involve a couple of weeks of 18 hour days, more than a few all-nighters, and when all else failed, calling in one of the original coders of - you guessed it - a contender for one of the upcoming SVR3 (System V Release 3) networking technologies, THE developer of PDU.....
His name has long been relegated to those parts of my primary memory I can no longer access, but I remember he came from the development group in Denver. A ten-year Bell Labs veteran, he was very passionate about PDU, and was convinced this was the right network strategy to move System V into the future. During the days and nights we worked together, he told me about his ten years at the labs, all the interesting projects he had worked on, the brilliant people he had worked with. He explained that he was coming up on his ten year anniversary soon, within weeks in fact, and he was excited to see what would happen with his career. He said that at ten years, you either become a supervisory manager or a distinguished member of technical staff. If neither happened, then you knew you had no future at the labs and should either accept your fate as a solidly contributing MTS (Member of Technical Staff) with no possibility for promotion or else seek fame and fortune elsewhere, leaving gracefully. He was excited about his work with PDU, and saw it as his ticket to a cushy DMTS (Distinguished Member of Technical Staff) role with all the privileges and accouterments pertaining thereto. I was excited for him, and hopeful that he would achieve his dreams. I felt privileged to work beside this technical genius, learning so much about Unix, network software, system software, and the AT&T Bell Labs corporate culture. Eventually we got everything up and running, our debugging and troubleshooting all those long days and late nights had paid off. Everything worked like a charm. The VAX 11/780 was now running a BETA version of SVR3 using PDU as its networking technology. We partied with the group, toasted our success, and this icon of a technocrat went back to his group in Denver. I wished him good luck, much success and prosperity in the future......
A couple of months went by, and we maintained email contact regarding the upgraded VAX 11/780, as well as new system software and other developments and timeframes for the SVR3 project. Since I worked in an applied research division (Transmission Switching Systems), not a basic research division like the Unix development group, I used all my contacts to find out what was going on with SVR3, and my Denver friend had a lot of good inside information. Eventually I finally got bold enough to ask him how his 10-year review went.....
I think we all know the end of this story. The PDU versus RFS wars raged on for months, and ultimately the RFS faction won out. My Denver friend and all his PDU efforts became a mere footnote in the annals of technology history. It was a huge disappointment for him, and was probably one of the causes for him to reach his 10 year career point without getting promoted to either a supervisory management role or the DMTS role he so coveted. Within six months he was sniffing around for other companies to work at, and within a year he was gone. I haven't heard from him since. He probably landed a good job at one of those networking companies that were starting to sprout up like weeds, Novell, Banyan, maybe something like that. I really never knew for sure. We lost touch. But I will always remember that time, when I worked at the feet of a genius, cutting my technical chops on networking systems sofware and hardware, on the big iron, before automated install scripts and visual aids and support hotlines, before the browser wars..... during the internecine battle within Bell Labs over PDU versus RFS.....
Of course, most bitheads weren't paying attention to what was going on with the System V side of the Unix house, but rather were more interested in what was going on with the BSD (Berkeley Software Distribution) side of the Unix house. The California regeants had already decided their upcoming release, still under development, was going to use a brand-spanking new technology called NFS (Network File Sharing) if they could only iron out all the kinks. History proved that NFS had legs, it was good foundation to build from. But I don't think anyone ever talks about PDU or RFS anymore, at least I haven't seen any recent articles about it. Just another faded memory of a dust-up between warring factions in the scrap-heap of commercially unsuccessful software technology.....
I was still a young pup by Bell Labs standards, and it was my job to upgrade existing mini-computers with new hardware and corresponding new system software. Mind you, these were not the days of packaged software and automated installation scripts with visual aids. These were the days of makefiles and option switches and command line orientation. I had gotten used to sysgen'ing new kernels on VAXen and 3B20 mini-computers - maybe it was fun the first dozen or so times I did it, but it was getting kinda old by now. Learning how to tweak the tunable parameters to optimize the system performance was exciting, and creating new /dev entries was a tad tedious, but formatting and partitioning all those physically huge disk drives (the size of frigging washing machines!!) and migrating all those user data files really required attention to detail and fortitude. So opening up the six-foot tall, eight-foot wide, three-foot deep blue monster and installing an Interlan NI1010A ethernet network card into the VAX's central nervous system shouldn't have been a big deal. Popping the card into an available slot wasn't an issue - sysgen'ing a new Unix kernel with the network interface software working properly proved to be more of a task than I had bargained for. Little did I know it would involve a couple of weeks of 18 hour days, more than a few all-nighters, and when all else failed, calling in one of the original coders of - you guessed it - a contender for one of the upcoming SVR3 (System V Release 3) networking technologies, THE developer of PDU.....
His name has long been relegated to those parts of my primary memory I can no longer access, but I remember he came from the development group in Denver. A ten-year Bell Labs veteran, he was very passionate about PDU, and was convinced this was the right network strategy to move System V into the future. During the days and nights we worked together, he told me about his ten years at the labs, all the interesting projects he had worked on, the brilliant people he had worked with. He explained that he was coming up on his ten year anniversary soon, within weeks in fact, and he was excited to see what would happen with his career. He said that at ten years, you either become a supervisory manager or a distinguished member of technical staff. If neither happened, then you knew you had no future at the labs and should either accept your fate as a solidly contributing MTS (Member of Technical Staff) with no possibility for promotion or else seek fame and fortune elsewhere, leaving gracefully. He was excited about his work with PDU, and saw it as his ticket to a cushy DMTS (Distinguished Member of Technical Staff) role with all the privileges and accouterments pertaining thereto. I was excited for him, and hopeful that he would achieve his dreams. I felt privileged to work beside this technical genius, learning so much about Unix, network software, system software, and the AT&T Bell Labs corporate culture. Eventually we got everything up and running, our debugging and troubleshooting all those long days and late nights had paid off. Everything worked like a charm. The VAX 11/780 was now running a BETA version of SVR3 using PDU as its networking technology. We partied with the group, toasted our success, and this icon of a technocrat went back to his group in Denver. I wished him good luck, much success and prosperity in the future......
A couple of months went by, and we maintained email contact regarding the upgraded VAX 11/780, as well as new system software and other developments and timeframes for the SVR3 project. Since I worked in an applied research division (Transmission Switching Systems), not a basic research division like the Unix development group, I used all my contacts to find out what was going on with SVR3, and my Denver friend had a lot of good inside information. Eventually I finally got bold enough to ask him how his 10-year review went.....
I think we all know the end of this story. The PDU versus RFS wars raged on for months, and ultimately the RFS faction won out. My Denver friend and all his PDU efforts became a mere footnote in the annals of technology history. It was a huge disappointment for him, and was probably one of the causes for him to reach his 10 year career point without getting promoted to either a supervisory management role or the DMTS role he so coveted. Within six months he was sniffing around for other companies to work at, and within a year he was gone. I haven't heard from him since. He probably landed a good job at one of those networking companies that were starting to sprout up like weeds, Novell, Banyan, maybe something like that. I really never knew for sure. We lost touch. But I will always remember that time, when I worked at the feet of a genius, cutting my technical chops on networking systems sofware and hardware, on the big iron, before automated install scripts and visual aids and support hotlines, before the browser wars..... during the internecine battle within Bell Labs over PDU versus RFS.....
Bell Labs blotto
The year was 1985. I had just earned my BSCS, graduating magna cum laude; I was feeling great, the future looked bright. I did a round of on-campus interviews with AT&T Bell Labs, and got hired into the Transmission Switching Systems division. My wife gave birth to our first child, a beautiful, bouncing baby girl. My new employer relocated me from the city to the suburbs, to be closer to the office, and I felt we were on our way to the good life. Life was so G-O-O-D!! Happiness abounded. There was no limit to the potential of possibilities to learn and grow, professionally and personally. My career in high-tech was just beginning......
My immediate supervision at the Labs was an Irish gentleman, keen of mind, slow of tongue, and absolutely glacial in decision making. I fast learned that corporations have a timeline to decision making that lies somewhere between watching an ant crawl from one end of the room to another, to sitting on the kitchen barstool waiting for the coffee pot to boil. My work at the Labs was very intriguing, I felt like a kid in a candy store, so many computers, so much software and hardware, so much to learn and experience and do. I worked in the computer center, with an Amdahl 5860 mainframe running UTS 370 Unix, several AT&T 3B20-S (simplex) minicomputers, an AT&T 3B20-D (duplex: wow, a dual-processor!) minicomputer, and a Digital Equipment VAXen farm as far as the eye could see: VAX 11/780, VAX 11/782, and VAX 11/785 minicomputers, the stalwart workhorses of the minicomputer era.
All the minicomputers were running on AT&T Bell Labs System V Unix. All the source code for the Unix operating system was readily and easily accessible, even encouraged, and my officemate (a Chinese gentleman many years my senior) suggested that the best way to learn the inner workings of this famed operating system was by reading the file init.c line by line, painstakingly going over every function call and sub-routine, following all the links to system header files and other kernel and user mode modules, and reading that source code. Like I said, for a computer scientist this was like being a kid in a candy store. I sucked it all up, and read voraciously, and within months I actually thought I was getting pretty knowledgeable, and soon realized I was becoming a self-described Unix bigot......
One of the recruiting tools AT&T Bell Labs used on candidates was the OYOC benefit. For the uninitiated, OYOC was One Year On Campus, which meant that any eligible employee could apply for and receive one year's tuition in a computer science master's degree program at the univerisity of your choosing. The best part was during this one year, you would still earn a percentage of your salary (I think it was like two-thirds, or something like that). What a deal! What a company! What a country! This was great. So after six months of working hard in the Transmission Switching Systems division at AT&T Bell Labs, I hit up my immediate supervision for the OYOC benefit. The conversation went something like this.
"I'd like to apply for OYOC." I queried plaintively during one of our weekly one-on-one meetings.
"Hmmm. I think its only for eligible employees." was the response.
"Waddayamean? I'm an eligible employee aint I?" my naivetee must have been obvious.
"Well, I'm not sure, I'll have to check" my immediate supervision said, somewhat less than forcefully.
"Hey, sure, no problem, let me know." I replied eagerly.
A week later my immediate supervision informed me that I did not meet the definition of an eligible employee. I asked him why not. He looked me straight in the eyes, and very slowly and clearly enunciated that eligible employees were defined as women and minorities. Always quick on my feet, and thinking fast, I told him I was a Boston Jew married to an Hispanic Catholic, and the world didn't have too many of those, so wasn't I a minority, too? We both laughed half-heartedly, but the reality started sinking in.....
I wasn't eligible for this program, so I wouldn't be able to finish my master's degree as fast and with my employer's recruitment tool as I thought. What a disappointment! This certainly was a large contributing factor to my deciding to accept the position at this company. What a let-down to be told I wasn't an eligible employee. How could I possibly have foreseen that if I got hired I wouldn't be an eligible employee?
Lesson number one: note to self - always read the fine print. Bell Labs blotto. If they could dupe me with this, what else was I living under a mis-conception with at my employer? The honeymoon was definitely over now...... the kid gloves were off. Welcome to the workplace. Someone steeped in occidental philosophy would think "Don't get mad, get even". Someone exposed to oriental disciplines would accept the knowledge of the experience and learn from it. I chose the latter, and began contemplating next steps.
My immediate supervision at the Labs was an Irish gentleman, keen of mind, slow of tongue, and absolutely glacial in decision making. I fast learned that corporations have a timeline to decision making that lies somewhere between watching an ant crawl from one end of the room to another, to sitting on the kitchen barstool waiting for the coffee pot to boil. My work at the Labs was very intriguing, I felt like a kid in a candy store, so many computers, so much software and hardware, so much to learn and experience and do. I worked in the computer center, with an Amdahl 5860 mainframe running UTS 370 Unix, several AT&T 3B20-S (simplex) minicomputers, an AT&T 3B20-D (duplex: wow, a dual-processor!) minicomputer, and a Digital Equipment VAXen farm as far as the eye could see: VAX 11/780, VAX 11/782, and VAX 11/785 minicomputers, the stalwart workhorses of the minicomputer era.
All the minicomputers were running on AT&T Bell Labs System V Unix. All the source code for the Unix operating system was readily and easily accessible, even encouraged, and my officemate (a Chinese gentleman many years my senior) suggested that the best way to learn the inner workings of this famed operating system was by reading the file init.c line by line, painstakingly going over every function call and sub-routine, following all the links to system header files and other kernel and user mode modules, and reading that source code. Like I said, for a computer scientist this was like being a kid in a candy store. I sucked it all up, and read voraciously, and within months I actually thought I was getting pretty knowledgeable, and soon realized I was becoming a self-described Unix bigot......
One of the recruiting tools AT&T Bell Labs used on candidates was the OYOC benefit. For the uninitiated, OYOC was One Year On Campus, which meant that any eligible employee could apply for and receive one year's tuition in a computer science master's degree program at the univerisity of your choosing. The best part was during this one year, you would still earn a percentage of your salary (I think it was like two-thirds, or something like that). What a deal! What a company! What a country! This was great. So after six months of working hard in the Transmission Switching Systems division at AT&T Bell Labs, I hit up my immediate supervision for the OYOC benefit. The conversation went something like this.
"I'd like to apply for OYOC." I queried plaintively during one of our weekly one-on-one meetings.
"Hmmm. I think its only for eligible employees." was the response.
"Waddayamean? I'm an eligible employee aint I?" my naivetee must have been obvious.
"Well, I'm not sure, I'll have to check" my immediate supervision said, somewhat less than forcefully.
"Hey, sure, no problem, let me know." I replied eagerly.
A week later my immediate supervision informed me that I did not meet the definition of an eligible employee. I asked him why not. He looked me straight in the eyes, and very slowly and clearly enunciated that eligible employees were defined as women and minorities. Always quick on my feet, and thinking fast, I told him I was a Boston Jew married to an Hispanic Catholic, and the world didn't have too many of those, so wasn't I a minority, too? We both laughed half-heartedly, but the reality started sinking in.....
I wasn't eligible for this program, so I wouldn't be able to finish my master's degree as fast and with my employer's recruitment tool as I thought. What a disappointment! This certainly was a large contributing factor to my deciding to accept the position at this company. What a let-down to be told I wasn't an eligible employee. How could I possibly have foreseen that if I got hired I wouldn't be an eligible employee?
Lesson number one: note to self - always read the fine print. Bell Labs blotto. If they could dupe me with this, what else was I living under a mis-conception with at my employer? The honeymoon was definitely over now...... the kid gloves were off. Welcome to the workplace. Someone steeped in occidental philosophy would think "Don't get mad, get even". Someone exposed to oriental disciplines would accept the knowledge of the experience and learn from it. I chose the latter, and began contemplating next steps.
Subscribe to:
Posts (Atom)
