I had worked for IBM Education for almost fourteen years, and I was both burned out on all the travel and also I wanted to go back to school to get a Master’s Degree in Computer Science. I was originally trained as an Electronics Engineer, but my career had steadily evolved to computer programming and testing, so I wanted to get more training in that area.
In 1998, when I saw an “open req” (internal job posting) in Boulder, I applied. Luckily I was interviewed by Mary B., the head of PSD Quality, and she remembered me from the Y2K conference. I was quickly hired and in my new office in Boulder — just a couple of aisles from my old office in Boulder.
My first two assignments were to lead projects that verified that the microcode in the large printers would be able to handle the new dates. That was pretty simple to do since the code was written recently and didn’t have the issues that old, legacy code typically had with dates. It was a simple job to verify that the printer hardware and its controlling software would continue to work correctly after Dec. 31, 1999. We found one small problem in a routine that handled service scheduling, and that was quickly fixed.
The next job I was assigned was a critical situation with our customer, the State University of New York, called SUNY. They had recently purchased our large printers and software to replace their Xerox machines. Although the IBM print data stream called AFP (actually much more than just a data stream, it is a complete print “architecture”) is documented and well known, the Xerox data stream called “metacode” was not documented. It was a bit of a secret known only to Xerox and we had to reverse engineer it in order to provide compatibility.
PSD had a special program (we called it a “tool”) that could convert Xerox metacode to our format of print stream. We called the program “Xport” since it could “port” Xerox metacode. We were constantly updating this program as customers would provide Xerox print streams that had something new in them. We would analyze the print data and modify our program to make the required conversions to AFP.
Things had not gone well at SUNY. The size of the conversion meant that Xport didn’t work very well and we were struggling to make the corrections and patches. In addition, the customer was adjusting to a completely different way of running their print center. When an IBM customer is not satisfied with how things are going, we have a process where we create a team specifically for solving that customer’s issues. It is the only way you can get rapid results from such a large corporation as ours and customers expected it from us. We cost a little more, but we guaranteed that, if there were problems, we would “darken the skies with three piece suits” until the problem was fixed. (That was a joke about IBM’ers all wearing suits and how we would fly in the experts to solve the problem.)
However, it is both expensive to fly a bunch of engineers to a customer site, and — besides that — customers were busy using their equipment to make money and didn’t need a bunch of IBMers in their way. So I was assigned the task of duplicating SUNY’s computer and printer configuration in our large laboratory in Boulder. We had the printers. We had copies of the Xerox jobs that needed conversion. What we didn’t have was a set of servers configured to match what SUNY had. So I started the project by traveling to New York to determine just how their print center was configured. Fortunately, they were a 100% IBM shop and all the equipment was made by us. I worked for five days with the local IBM support engineers and got all the specifications for their system, all the software they were using — versions and patches, as well as how their communication and networks were set up.
Now I headed back to Boulder to build a twin. The problem was, I was new and didn’t really know all the people I would need to beg, borrow, or steal the needed hardware to install in my lab. Also, I didn’t really know how long it would take to get a working copy of the SUNY installation, much less how long it would take us to work out all the technical issues that we were trying to solve. So I did what any good project manager does, I guessed. With one finger in the air, and twenty plus years of “gut feel,” I estimated six weeks. So I told the customer ten weeks. There was some push back, but they agreed, and I had my schedule. Still assuming that it would only take about six weeks of work to build and test our duplicate printing installation and still allow time to verify all the technical issues that SUNY had, I went around asking to borrow hardware for two months. I would promise on Tom Watson’s grave that I would have the equipment back in the eight week’s time. The key is sincerity. Once you can fake that, you’ve got it made!
I was pleasantly surprised how easy it was to gather the equipment since we had a large development and testing organization and lots of equipment was available. I was also very pleasantly surprised how quickly we could put it all together and soon were running print jobs as the identical twin of SUNY’s configuration. I had some help from the New York support engineers who spent a week in Boulder helping me with the final configuration and plenty of support from various experts in Boulder, but I did most of the work myself. It was a great and fun learning experience for me.
What I hadn’t estimated correctly was how long it took the development team to fix all the problems with Xport. We had a good updated copy ready in eight weeks and sent it to SUNY. They were both happy that the fixes allowed them to run most of their Xerox print jobs correctly and they had been talked into it taking ten weeks, so we exceeded expectations. However, they did not agree to close the critical situation until all of the identified issues were resolved. Plus, as is par for the course, they kept finding new problems and adding them to their “conditions of satisfaction.”
In the mean time, I was having a lot of fun and learning all kinds of new things. Mostly I was a team of one as far as setup and configuration was concerned. I would contact groups like the network support people to help me configure the token-ring network. (We had both token-ring and Ethernet, and even 360 channel networks in our lab.) The most interesting part was the configuration of InfoPrint Manager, the core software. It was designed as a multi-threaded, multi-processor program. There was one process that handled all the input and queuing. Another part did the print transform work such as converting graphics like jpeg or tiff or converting formats such as HP PCL or Adobe Postscript. Finally, the third process handled communications with printers via a concept called “virtual queues.” You could install the complete package to run on one large server, or you could use multiple servers and divide up the work. Using a network file system and remote process operation, it was possible to configure InfoPrint Manager on a group of servers that then operated as a single, powerful and efficient system. That was how SUNY had set it up.
This powerful software was used by such large customers as the IRS. All tax refund checks are printed using InfoPrint Manager, for example. The most powerful way to configure InfoPrint Manger or IPM was using a separate server for each of the processes. In fact, you could even use more than three servers if you had a very large number of printers or many sources of input print files. I had borrowed four powerful IBM POWERServers from the development team in Boulder to emulate the SUNY configuration. This was few years ago, but I think I used F80 AIX servers in the configuration. These printing systems are a little bit more complicated than you home printer. Imagine printing all the statements for the telephone or cell phone company or all the bank statements or broker statements. These were the kinds of jobs done by our high-end systems.
I learned more about AIX (IBM’s version of UNIX) and system administration during the weeks I was setting up and configuring this system than I learned at any other time. I always enjoy learning new things and I was right at the developer’s elbow as they modified the Xport program to accommodate some new Xerox data structure we found in the SUNY print data. It was a fun time and I was going in to work at 5:00 AM and staying to 10:00 at night. It was just fun for me and didn’t seem like work at all.
It was OK with me if the customer kept discovering new problems for us to solve as we were quickly finding the source of the problems and fixing them fast thanks to our local system. Once we confirmed that the fix worked on our test system, I was very confident it would work when installed at the customer location. Then I got a phone call from one of the managers that I had borrowed servers from. He said the two months were up, and he wanted to know when he was going to get his computers back. I could tell he was on his speaker phone and I didn’t know who else was in his office with him. I laughed and said that we were close, but might need the equipment for a few more weeks. There was complete silence on the other end of the line and then the manager said that, “No-one was laughing at his end.” I said, “I’m laughing to keep from crying.” He said he wanted me to come over to his office right away and explain why I was not able to keep our bargain about return of the servers.
When I got to his office, there was a person there I knew from my earlier teaching. He had been in my fifteen-week programmer training class in Boulder about ten years earlier. The manager started with a stern look on his face telling me that he needed the servers back to keep an important schedule, and I would have to explain to his team lead why I could not keep a clear commitment I had made with him in the prior months. I was petrified. If he took back his servers, I didn’t know where I would get more, or how long it would take me to reconfigure my test system.
Then his team lead, my former student, laughed and said he would be fine if I kept the servers for a few more weeks. It turned out they were all just pulling the chain on the new guy. The manager told me he could hear me sweating on the phone!
Later, after I had worked at PSD for over ten years, I had both the close relationships and the personal reputation that prevented any of these kinds of troubles. But when I was the new guy, and didn’t know most of my coworkers, it was very touch and go for me. I’ve always known that IBMers would be willing to help and cooperate to the fullest. It is in their genes — blue genes. But they also loved to haze the new guy.
One of the main skills any project manager can have is the confidence of his or her coworkers. I was fortunate that my time teaching had built my reputation with engineers and management as a person who knew what he was doing and someone you could trust. It paid off so many times for me during my thirty-three year career. People rarely asked me to justify any request I made. They assumed I knew what I was doing and just provided what I asked. Still, sometimes I had to laugh to keep from crying. I also had lots of chances to pay back that original manager. I had to approve the quality of all code produced by his department. Sometimes I made him sweat — and then we would laugh.
Oh, we finally found and fixed every problem that SUNY had reported and got them running smoothly. They ended up buying all the system from us. (If it had not worked, we would have taken it back.) I was given credit for saving a multimillion-dollar sale, and that raised my reputation with the sales force and top management. Finally, the original manager that had hired me to PSD dropped by my office and she told me that she had been congratulated for hiring me. Nothing better than when the top boss tells you that your worked helped their reputation. I was now an accepted and valued member of the IBM Printing Systems Division.
I remained with them for the last fourteen years of my career. Now it is all just a sweat, err, I mean “sweet” memory.
No comments:
Post a Comment