to Cyreenik book index
While storm clouds were growing over Novell all through 1981 there was lots of sunshine too. One of the bright spots was the evolution and development of the local area network.
Novell’s product line, intended and real, was never static. It evolved from Day One, in logical, internally self-consistent ways. Jack started the company on his vision of a multi-CPU minicomputer—something that would break out of the limited-applicable-size constraint that minicomputers of the ’70s offered. This minicomputer would need terminals and printers—something Jack was particularly experienced at selling, so why not build these too? Build them first, in fact, to finance the development costs entailed in designing the minicomputer.
So in the summer of ’80, that’s what the potential product line consisted of.
By fall of ’80 it was clear that Safeguard would be doing the bulk of the financing. They wanted something their Business Systems dealers could sell. George said, “These people certainly can’t sell a multi-user mini. This means a standalone microcomputer … no problem, we’ll convert our terminal into one. Doing so is an industry trend right now.” Thus the terminal computer was born and added to the product line as another way of bringing in revenue to support the minicomputer development.
In the spring of ’81 Jack was still pursuing his NovellWriter dream. Since none of his commercial contacts had born fruit, he decided to end-run, the same way he had with AutoGen, and he contracted with some BYU grad students to develop a word processor.
Just days before the BYU programmers who would become SuperSet drove into the sparsely populated parking lots at Industrial Park Drive, Novell’s top management conducted a brainstorming session. The subject: Sales of the terminal computer were growing too slowly and something needed to be done. (It was clear that the mini would be a long time coming, so that couldn’t be part of the solution.)
The managers assessed the terminal computer they had created:
Among those top managers, the LAN idea had a lot of supporters:
Jack was aware that two startup companies, Corvus and Nestar, were selling PC-connecting LANs, so he could see a market developing.
For Jack and Sherrill the LAN was a way to keep the 68000 chip as part of the product line, even if the multi-CPU minicomputer product was delayed.
For Dennis (the Ph.D. candidate and parttime Novell advisor), the LAN was a different way to transcend the limited-range-of-users problem that afflicted all traditional minicomputer designs. Instead of adding CPU power by putting additional cards into the central box, the CPU power would be added with each terminal computer added to the system.
For Larry it meant something to sell sooner rather than later.
With so many top managers going for the idea, it turned out that when the programmers from BYU arrived Jack’s word processor was never mentioned.
Comdex was coming!
The temporary BYU programmers—Drew, Dale, Kyle, and Mark—reported to Phil, the head of Software. He and his regular staff were working long and hard on making the terminal computer a suitable Safeguard product.
Phil introduced the expression “creeping feature creature” into Roger’s lexicon. When new ideas came up he was often the one to say, “Sure it’s nice, but do we really need it to sell product?”
When the LAN project came to his doorstep it was just another feature-adding project that Phil didn’t have the resources to devote to. So Jack borrowed his new temporary talent, the BYU boys, to get a LAN demonstration built for Comdex 81.
Dale and Kyle started working on the terminal computer side. Their task was to pry the CP/M operating system apart far enough so they could get disk requests to flow out over a wire to a remote file server rather than go to an internal disk controller. The programmers needed something to test their work on, so Drew took another of the terminal computers and started developing a test-bed file server.
Dale related, “We’d been in this position once before. A year earlier we were working as part of a team project and the other part of the team failed to deliver. We had no way of proving our part worked, so we didn’t get paid. This time we weren’t taking any chances.”
Fate proved the wisdom of this strategy. The fellow that was developing the 68000 file server side had a motorcycle accident. In a flurry of long hours and last-minute hustle it was the Z-80–based test-bed file server, stuck over the top of the 68000 board and using RS-232 connections, that was shown at Comdex.
This demonstration system was an example of the “blue smoke and mirrors”—an expression Andy liked to use—that Novell used to make a point at Comdex 81. That first system was never built to be sold, but solely to show what Novell was going to be up to in the coming months.
This practice is controversial: To some it is fooling the public because the thing being demonstrated may or may not come to fruition.
The value of showing off such a may-become-a-product is that it reduces risk to both vendors and consumers. It’s a test-marketing step that helps vendors find out how valuable potential customers perceive a product to be and what adjustments need to be made to make it even more valuable.
Not bringing such prototypes to a trade show raises the cost of product introductions by forcing companies to spend more money before demand is proven. We end up with more Edsel cars and Premier cigarettes (a forerunner of the electronic cigarettes of the 2010s), where a lot of money is spent making a product that won’t sell. Or we end up with more situations like America losing out on fax machines, where a market isn’t tapped because the demand looks too risky for the amount of up-front money that must be committed.
Blue smoke and mirrors—prototyping—is a powerful cost-reduction and feature-tweaking tool for marketers. But like any other powerful tool, it can be abused. Novell used it well at Comdex 81.
The LAN demonstration at Comdex was a hit; lots of people were interested. George and Jack had pulled off another coup. They’d come to Comdex 80 with nothing but promises to be a big company. At 81 they were showing off cutting-edge products: The printer, the personal computer with a hard disk, and the LAN.
It didn’t take Jack long to sense that the LAN concept was generating more interest than he had expected. Then, at a lull in the bustle of the show, Drew pulled Jack aside.
“You know, Jack, this LAN business is something we programmers have been thinking about between us before now. And what you’ve been describing here at the show is close to some of the ideas we’ve developed.”
Drew and Jack headed home from Comdex early. Within a week the temporary programmers who came to build a word processor were formally mustered in as the core of the LAN development team.
One of the first issues the proto-SuperSet team faced was the question of how to split the disk-controlling duties between the personal computers and the file server. The simplest and quickest approach was to let each personal computer do the bulk of the work, the most important piece of that work being deciding where on the disk to store the data. This is the disk server approach. The disadvantage is that the file server can’t coordinate between the various computers easily.
There’s a quick and easy way to solve that problem: Don’t have any coordination. Allocate each computer a fixed portion of the hard disk with no overlap. This is called disk partitioning and it’s the simplest of the disk server approaches.
Disk server: Quick to develop; simple in concept. Larry Edwards and the sales force loved it. They could say, “Yes, we have a LAN,” and be selling it within months. The benefits were so compelling that most of Novell’s early LAN operating system competitors were disk server-based.
The alternative is the file server concept: Let the file server operating system decide where to store data on the disk and handle coordination between the various personal computers’ requests. This requires it to do more and requires more modification of the personal computer operating system. The benefits are more coordination between the personal computers and more efficient use of the disk storage. Partitions aren’t required.
There was one other serendipitous difference between the two: File service requires more horsepower from the processor on the file server than disk service does. Novell’s plan to use the more powerful 16-bit 68000 for the file server, while most of the competitive units were based on the 8-bit Z-80, made file service easier for the Novell team to develop than it would be for competitive teams.
Thoughts of disk service versus file service were churning through the minds of the future SuperSet in those weeks after Comdex 81. The more they thought, they more they wanted to develop file service, and not just file service but file service with system fault tolerance (an error recovery system that we’ll be looking at in detail later).
Doing this would be difficult in the face of Sales demands for “something I can sell today”, but as it turned out other events in the company were going to force themselves into the limelight and give the team the time to follow their dream.
One of those events was the firing of Jack Davis, of which more is said in the next chapter.
to Cyreenik book index