Taking the initiative is a desirable trait

Leading the Way

Article from Issue 156/2013

"maddog" describes how forging your own path can sometimes lead to better results than simply following instructions.

Often, the first step in consulting is to interview, and be interviewed by, the client to see if a best fit exists. During a recent interview with a potential client, I spoke of some of my lesser known exploits and, after a while, the interviewer smiled and said, "You initiate things on your own … you do not wait to be told to do things. I like that." I found it interesting that he was the first person in a long time to pick up on what I believe is a desirable trait in an employee.

Back in about 1989, I was a Product Manager for the Ultrix-32 operating system from Digital Equipment Corporation. The company was distributing Ultrix-32, a bare-bones Unix system, on three TK50 tape cartridges. The TK50 was at that time a Digital proprietary streaming tape cartridge called "Digital Linear Tape" that held approximately 95MB of data. Each cartridge cost about US$ 100 to purchase and manufacture, so the entire distribution cost about US$ 300 to make, and we sold the distribution for US$  1,200.

At that time, CD-ROMs were starting to make their way into the computer industry. In those days, if you wanted to master a CD-ROM in a hurry (a week turnaround time), it cost about US$ 100,000 to do the master, then US$ 5 each for the first 1,000 CDs, and the costs went down rapidly after that.

The use of TK50 tape did not allow for an easy installation because you only had the RAM memory of the machine to hold programs for tailoring the disk and readying the disk for installation. As a product manager, I theorized that we could boot a CD-ROM and run off the CD-ROM as a disk, having all the tools on the CD-ROM to tailor the disk before doing the actual distribution. This might seem obvious in the day of the "Live CD," but at the time, the idea was revolutionary.

Unfortunately, the emerging standards for ISO-9660 were set up to reflect only MS-DOS and VMS styles of filesystems, with eight uppercase characters and a three-letter extension for file names, only eight levels of directory structure, and various other issues that prevented "Unix-like" filesystems.

Andrew Young of "Young Minds" authored the Rock Ridge Interchange Protocol proposal, which layered on top of ISO-9660 and provided extensions like 255-character file names (in both upper and lower case), symbolic links, and other POSIX requirements. Young contacted me, and I went to talk to the editor of the ISO-9660 standard of that time – a Digital employee working for VMS. After a spirited discussion (some unkind people would have used the term "blackmail"), the editor agreed to consider the extensions.

Now the CD-ROM standard included everything Unix needed, but my own management refused to put this type of support into the operating system, citing no customer demand and saying we were too close to field test of the release to put in new functionality.

I was contacted by Paul Shaughnessy,1 a young engineer in the Ultrix group, who informed me that he had most of the Rock Ridge functionality in the kernel already. It was "latent support," meaning, if you did not try to use the code, it did not affect anything.

Gleefully, I waited until after field test was distributed and then pointed out to management what Paul had done. Furious that we had "jeopardized field test," management did agree to let us access some already existing CD-ROMs manufactured to the CD-ROM standard. Paul's code worked flawlessly.

I kept careful track of who tested the code throughout the field test. There were no issues with properly created CD-ROMs following either the formal ISO-9660 standard or the Rock Ridge Interchange Protocol (RRIP) that later became IEEE P1282, an extension to ISO-9660.

I participated in writing the Software Product Description, the legal document detailing the supported parts of the release and the functionality, improving the description of the CD-ROM functionality, stating we could always remove it at the last minute if the functionality failed field test.

At the end of the field test, we decided to support the code officially. The engineering manager came up to me and said, "You did it again, maddog! You managed to get functionality in without having a plan." I only smiled.

Buy this article as PDF

Express-Checkout as PDF
Price $2.95
(incl. VAT)

Buy Linux Magazine

Get it on Google Play

US / Canada

Get it on Google Play

UK / Australia

Related content

comments powered by Disqus
Subscribe to our Linux Newsletters
Find Linux and Open Source Jobs
Subscribe to our ADMIN Newsletters

Support Our Work

Linux Magazine content is made possible with support from readers like you. Please consider contributing when you’ve found an article to be beneficial.

Learn More