Dr. Rudd Canaday is Entefy’s Software Architecture Fellow. He is a co-inventor of the UNIX operating system and was a graduate student at MIT’s pioneering Computer Science & Artificial Intelligence Lab. Rudd shares some of his experiences during computing’s early days below—as well as a timeless career insight.
In 1975, when I was 37, I got my first and only job at Bell Labs that was not in research. Bell Labs had written, a long time before, an elaborate software system named DIR/ECT, for DIRECTORY, used in printing white pages phone books. This sounds like a simple job, but the rules for how listings were arranged, alphabetized, and displayed in the white pages were arcane, dating back to the turn of the 20th century. This software was obsolete, using batch processing with data on magnetic tapes. It was notoriously hard to use and error prone. I was given the unenviable task of figuring out what could be done.
The head of the department maintaining the DIR/ECT system and I looked at the system and decided that it was not practical to bring it into the (then) modern on-line age. We decided that a new system needed to be built. Officially named “DIR/ECT II,” we called it “the upgrade” to emphasize that it would be fully compatible with the old system. The work of maintaining the old system, and of building a new one, was funded by the “operating companies,” the telephone companies that were part of AT&T at the time. So, the DIR/ECT department head and I had to convince the operating companies that a new system was needed, and that they should fund it. Which wasn’t that difficult, since the old system was so challenging to use. My estimate to get the job done? Three years.
I formed a new department focused on the upgrade that eventually grew to 50 people under 7 supervisors. Meanwhile next door, the original DIR/ECT department of about 30 people maintained the old system.
DIR/ECT II was by far the largest department I had managed—and was to be my least successful managerial experience. Since it was being paid for by the AT&T operating companies, I had the job of presenting the project status in a twice-yearly meeting and convincing them to continue funding the project. At first these meetings were easy, but as we missed our deadlines they became more difficult and much more expensive in computer time. In the end, it took us 5 years, not 3, to complete DIR/ECT II.
Part of the problem was my decision early on that we would build the system on UNIX using a DEC (Digital Equipment Corp.) minicomputer. DIR/ECT II was the first AT&T product built on UNIX, and perhaps the first on a minicomputer. The decision to use UNIX was controversial largely because UNIX only ran on minicomputers. It turned out to be an unwise decision. The computational demands of the system were much higher than I had originally anticipated.
As a result, a couple of years into the project we saw that we needed a faster machine. Fortunately, DEC was about to introduce a new machine that promised faster speed. After all, previous releases of new DEC machines had each doubled the speed of their predecessors. But this time the new machine didn’t perform as well. Without the extra speed that we had been counting on, we were forced to spend quite a bit of time trying to make our system more efficient. But when we finally went live with DIR/ECT II, performance was only marginal.
Meanwhile, the DIR/ECT department head was wrestling with the problem of motivating his people to work on a dinosaur while next door their colleagues were building the sexy new system. To win, he decided to challenge his team to improve the old system so drastically that by the time DIR/ECT II would be available the operating companies wouldn’t see a need for the new system. No one thought this was possible. The old system was just too cumbersome.
In the end, though, we agreed that the challenge would be good for his team. My colleague invented the slogan “Obviate the Upgrade,” and threw down the gauntlet. To our surprise, by the time my team finished DIR/ECT II, the old system had been transformed into a modern, on-line system. And, indeed, after the new system had successfully passed its trial period, none of the operating companies wanted it and it was abandoned.
Moral of the story? Competition isn’t always a bad thing as it can lead teams to accomplish remarkable things.