It was the most intensive and costly effort in personal computer history

Reprinted from Personal Computing, issue 3/1983, pp. 96-186. Part 2 of the article “New from Apple: Lisa and the IIe.”

Lisa prototype. Photograph by Mike Blake

Apple. That funky bastion of Computing Power for the People, sporting its rainbow-striped logo like a slap in the face to big business and corporate chic. The company that cared more about creative technology than making a buck, or so the basement hackers who bought the first Apples believed. That company has slowly grown up, sold its stock like any other public corporation, and hired the best advertising and public relations agencies in Silicon Valley. The hackers’ company has now decided to tap the Fortune 1000 crowd.

In 1979, Apple management decided to build an office system for the eighties. By December, a core group of designers was kicking around some preliminary ideas. The group included Apple co-founder and chairman of the board Steve Jobs, vice-president for software development John Couch, 12 software engineers, and 6 hardware designers. Their goal was the creation of a machine that would copy and complement the way people naturally work.

Early in its work the group saw Smalltalk, the revolutionary personal computer programming system designed in the 1970s at the Xerox Palo Alto Research Center. The Smalltalk system features a bitmapped video display, mouse control, and a so-called modeless environment.

Says Bruce Daniels, an Apple technical manager, “We were turned on by Smalltalk because it fit our idea of an easy-to-use system, and we started talking about doing something like it. We didn’t have to sell the idea to Steve [Jobs]. Like everyone else, he instantly fell in love with it.”

The group liked Smalltalk so much that they were later to court and hire Xerox’s Larry Tesler, a specialist in both user-interface design as well as the Smalltalk programming environment. Tesler, in fact, had given the group its demonstration at Xerox headquarters in Palo Alto, where he had worked on the Smalltalk design team. He came to Apple, he says, because he wanted to see the ideas he worked on “in hundreds of thousands of machines. Apple could develop products fast and at lower cost,” he adds. Some 15 or 20 Xerox engineers were to migrate to Apple during the course of the Lisa project, most of them coming for the same reason Tesler did – to see their work widely marketed.

With the target now in its sights, Apple created Personal Office Systems, a new corporate entity headed by John Couch, to support the growing team of engineering and marketing specialists. The team started by balancing engineering and marketing wish lists.

The engineering group wanted a machine that would be transparent to the user, intuitively easy to operate. “Of course marketing wanted every feature in the world for no price at all – and they wanted it yesterday,” says Daniels jokingly. “Together we slowly worked out compromises and engineering tradeoffs. In the end, we didn’t really deviate much from our basic goals.”

Architecture

Lisa design team members (l. to r.) Wayne Rosing, Larry Tesler, and Bruce Daniels. Photograph by John Blaustein

“We designed Lisa’s architecture by committee,” says Tesler. “That’s usually a bad idea. Several people wanted to be the architect and several offered to be, but no one person emerged who had the breadth of experience we felt was necessary. Nobody likes designing by committee – and there was a time when we desperately wanted a single architect to appear – but the result was actually the same. The process was just more painful,” he laughs.

The core group broke up into smaller groups to scheme out the architecture. Each would work on its own particular area of expertise and bring the results back to the larger group to be considered as a part of the grand design. “Sometimes people would go away with an idea and come back with the first cut at it. They might have thought it was the final cut, but we knew it was the first one. Then we’d test it and go on from there,” Tesler recalls. “Most of our people hadn’t done anything like this before, so we had to test ideas constantly, learn from mistakes, and persevere.” As Daniels expresses it, “We cycled all of it over and over to perfection.”

Daniels became the team’s unofficial historian. He’d been with the project through most of its existence and was one of the few people to be transferred from another division at Apple. A graduate of the Massachusetts Institute of Technology, Daniels came to the company from Hewlett-Packard “because it was a chance to do something really significant,” he says. “HP was a large organization and the kind of place where you had to work your way up the ladder very slowly. Apple is exciting.”

Daniels maintained his excitement throughout the project. He shows visitors an original Lisa I breadboard (prototype) with its homebrewed guts and blue wires streaming out of the back and sides. Daniels also keeps the team’s family album, filled with the expected candids of clowning staff members as well as snapshots of the first Lisa display screens. That first “crude but workable” machine was born in the late spring of 1980. It lacked memory, ran off an Apple II to some extent, and was missing any number of comfortable features, but it was enough to get going on software design and the feature that was all-important from the beginning – the user interface.

User interface

What came out of the spring and early summer were preliminary designs for Lisa’s user interface (that collection of features through which the user and the machine communicate). The user interface, thought of at Apple as a veneer uniting the entire system, is one of the machine’s revolutionary features. The user interface is a combination of hardware and software designs that comprise what the system looks like and “how it feels to users,” says Tesler. It includes such items as the non-glare display screen, keyboard layout, screen resolution, and the built-in software features that make Lisa easy to use.

A 35-page document called the User Interface Standard emerged in the summer of 1980. “It helped to make all the applications conform to a standard and included things programmers shouldn’t do as well as things they should,” says Tesler. “For instance, one of the things we avoided was modes. Some programmers take it for granted that you have to have them, but figuring out which one you’re in and how you get in and out of them is confusing to users. We devised what is essentially a modeless system. The few remaining modes are quite easy to understand.”

When it came to design by committee, the user interface was perhaps the most difficult issue to be worked out. “Hundreds of issues were controversial,” Tesler says. “The hardware and software issues that came up tended to concern just a few people. After all, not everyone can talk about what gate or what routine to use, but everyone can talk about the user interface. It affected the whole division because Training had an opinion, Marketing had an opinion, Publications had an opinion, managers had opinions, the software expert implementing the application had an opinion, and kibitzers on the sidelines naturally had opinions.”

To bring some objectivity into this sea of opinion, the Lisa design crew developed a series of testing techniques. In order to judge how naive users would react, team members would find new Apple employees through the personnel department. After screening the test subjects, Tesler would put them through a series of Lisa tests. “Sometimes we found out that all the proposed interfaces were wrong. We had a couple of real beauties when the testers couldn’t use any of the versions we’d give to them, and they’d say, ‘Why don’t you just do it this way?’ It would be obvious that that was the way to do it, and we couldn’t believe we had completely missed it,” Tesler says.

What Lisa engineering managers were particularly good at, however, was consciously keeping a prototype of the end user in mind during the designing process. This user was a faceless “businessperson with neither the time nor the inclination to understand computers,” says Daniels. For Wayne Rosing, engineering director of the entire Lisa team, the prototype wasn’t quite so anonymous. “Our secret user was John Couch. We figured if he could learn the system and use it, we were okay. He’s the busiest manager in the world. So, in any dispute, I’d ask, ‘Will John Couch use that feature?’ If the response was no, I’d say, ‘Then why are we arguing about it?’ ”

Other decisions about the user interface came throughout the year – doorless disk drives with an eject button to prohibit users from accidentally removing a disk at the wrong time, legend changes on the keyboard, and overall designs to make the machine easy to service. Ease of service is “part of the broader user interface,” says Tesler. “It’s part of how people perceive the entire system.”

Building a team

Once the architecture was complete, the user interface roughed out, and several versions of Lisa’s hardware rigged up, the core group expanded rapidly during September and October of 1980. From a group of some 18 hardware and software designers, Lisa’s team grew to 96 by late 1982, with almost another 100 in marketing, training, manufacturing, and administration.

Most of the engineers were experienced and drawn from other companies, with only a very few hired directly out of school. “There’s an average of 10 years’ experience in the applications group,” says Tesler.

Lisa software specialist Marian Catelain. Photograph by Rachael Wrege

Many of the people who came to work on Lisa were disillusioned with the firms they left behind. Like Tesler and Daniels, database-applications specialist Marian Catelain wanted to see her ideas out on the open market. At Burroughs Corporation, she says, “I built a system that was comparable to this one in magnitude and in the fact that it used leading-edge technology. Just when we were about done, [management] canceled the project. It was a tremendous blow I to me. I really wanted to build a system that would get out in the world and that people would use.”

Perhaps the most intriguing facet of the Lisa team was the vision the members all shared. Daniels calls it The Dream. “We all feel the same way – it’s the dream we’ve all bought into. Software and computers were just a mechanism to achieve that. You look out there and the computers exist for no reason except that they could be done – they reached the evolution where people could fit things together, so they did. Many programmers and engineers build things for themselves, but we’ve tried very hard not to do that. We test our experience to make sure we're doing things the right way.”

“We got a hundred people focused around a common goal,” Rosing adds. “That’s not an easy thing to do.” Rosing sums up the personal development neatly when he says, “We spent one year building a team and the next year building a product.”

Putting the team to work

That the team was already focused on a single vision and had worked out communications strategies early was fortunate. When the group was fully staffed, the project ready to go, and the basic schemes for the machine hammered out, the dark specter of schedules appeared. The group was to take all of 1981 and 1982 to build Lisa.

Somewhere along the way, almost everyone had to depend on someone else to finish a particular project. “We were developing everything in parallel,” says Tesler. “Even though we had a fundamental philosophy about it, having the various projects going on at the same time meant you were never sure you were going to get what you needed from the person you needed it from.” The team was able to live with the problem and the unpredictable schedules it created.

Instead of emulating Lisa’s functions on a larger computer, the programmers worked directly with Lisa hardware. While this added to the development time, says Rosing, “it paid off in the end because you develop better tools working that way.”

Of course, Rosing did try to schedule or estimate how long the team would take to perform various feats of design. “We came up with schedules all the time,” he says, “but they were all myths.”

The project was never compromised by scheduling, Daniels asserts. “It was a dream, a goal, and while we were willing to make compromises to get it out expeditiously, the dream was the major force.” On the other hand, Tesler reminds us, the team was aware that the division had been in existence for two years, had spent $50 million in development, and had not yet made any money for Apple.

Each engineer created his or her individual work schedule. Some came in Monday through Friday, 9 to 5; some worked all day and all night. “Some felt pressure in a personal way,” says Tesler. “To reach a certain milestone they’d work weekends and nights, skip vacations, skip conferences. And when they weren’t under a lot of pressure, they’d take it easy. We decided a long time ago that because this project would last more than a few months, we couldn’t have constant pressure on everyone. They’d crack.”

Rosing too was particularly proud of the team when it came to scheduling and communicating. “They’re all professionals. One thing I never had to get involved in was pushing – that sweatshop kind of stuff that’s come to be associated with an effort like this. I’m appalled to read things like The Soul of a New Machine [Little, Brown; 1981] and know that people think that’s the way to do engineering. It’s a way, but it’s not consistent with the values at Apple. I couldn’t pull that kind of stuff and get away with it with this staff – they’d throw me in the nearest trash compactor.”

“This was a labor of love,” Rosing continues. “When pressure came in from the outside, I took it. Our way of going about this has been the secret of our success, and even if it did cost us six months, it wouldn’t have been worth it any other way. Half the staff would leave at the end and the rest of us would be raving maniacs. The product would have suffered.”

Taking risks

Scheduling Lisa’s birthday was made even more difficult by the risks the development team took in designing the machine. At the time that Lisa’s engineers decided to use the Motorola 68000 microprocessor, it was in experimental stages and the team was “getting the chips one at a time from the local sales engineer,” Daniels remembers.

It was a gamble – there were no contingency plans if the chip never reached production. “The philosophy at Apple is ‘Go for It’,” says Rosing with a smile. “Whenever you have a contingency plan, you dissipate some of your resources.”

The hardest and riskiest part of Lisa’s design, says Rosing, was the development of floppy-disk drives built into the machine. Code-named Twiggy drives, these devices offer 50 to 60 percent higher density than standard models, thanks to some brand-new design ideas and technologies. “We had to keep a place open for Twiggy – I had to put my foot down and risk my job to do it, but I knew the designers would come through,” emphasizes Rosing.

Printers were also an issue. For a while the team didn’t know if it could program the software to drive them as planned. “Theoretically it was possible for us to use the printers in the way we wanted to, but the printer manufacturer didn’t believe it could be done. It took the printer people over two years, but we did it,” Rosing says.

The team was also anxious about other products that could be released to compete with Lisa. “We thought someone else might surprise us and come out with a machine like ours. We’d hear commercials that mentioned ‘bit-mapped’ or ‘icons‘ and we‘d rush out to see it,” Tesler says.

Champagne milestones

Despite the risks and scheduling concerns to deal with, the Lisa team met milestones with champagne and celebrations. In March 1982, a number of functions started coming together for the first time. Roughly 80 percent of the applications code was complete, the development tools had been polished up, and the intrinsic units (a mechanism for sharing code between applications) were finished. The printers started to work, a major revision of the desktop manager (the filing system that makes Lisa’s screen look like the top of your desk) was complete, and the icons used in making commands on the system were in place. “We thought then that we understood how to build the rest of the system,” says Rosing.

One summer day in 1982 brought two major milestones to the crew (as well as “an inordinate amount of champagne,” says a staff member). In the early afternoon, the team got all the applications up and running at the same time in a single machine. “So out came the champagne,” says Tesler. Although the team had planned to spend a few more weeks working on the capability to exchange information between applications, “some of the guys got a little high and decided to go try it anyway. It worked, and a few hours later we were pouring again.”

Security

Although rumors about the Lisa project were abroad from its inception, the computer industry was especially buzzing with gossip during Lisa’s last six months of development. Many of the leaks may have come from job applicants who were not hired, from venture capitalists evaluating Apple contractors, or from the “Sneaks” – sneak previews of Lisa given to major firms interested in buying the machine when it was released.

Apple employees honored the trust placed in them. In fact, the team members were allowed to take Lisas home with them with the only stipulation being that they keep the disks separate from the machines in case of burglary. “We tried to be as secure as we could without creating a discouraging environment for the people who work here,” explains Rosing. “We figured the chance of one of the machines being stolen was worth the risk when weighed against the productivity increase of people working at home.”

Rumors also flew around the industry about the name Lisa. Officially, say Apple public relations people and design staff, the name stands for Local Integrated Software Architecture. The unofficial story has it that Lisa was the name of Steve Jobs’s girlfriend at the time.

Fine tuning and finalizing

As this is being written, the Lisa team is just finishing up its project – fine tuning, they call it. They are also being very careful about how they put their new electronic child on the marketplace.

“We want to make this like a car,” Tesler explains. “You get into one and you say, ‘Well, it works.’ You get into another and say, ‘This one feels great on the road – it feels right’ That’s the way we want Lisa to be. Fine-tuned. High-class.”

The engineers are also getting a look at their own particular signatures on the machine. It was a group effort, “but even people who have been with us for only a few months can look at the machine and say, ‘That was my idea, that’s my code,’ ” says Tesler.

For Tesler, the signature was primarily in the user-interface design. For Daniels, “it was a little piece of me here and there in managing a lot of other people.” For Catelain, it was “a myriad of details affecting the applications.”

The engineers say they’re proud of their products. They say the technology will trickle down to less expensive machines. Integration, information transfer, and user interface, say the engineers, will be the new names of the game for a while.

In a sense, the engineers are disbanding now, although Apple is doing everything it can to hold the team together. Rosing is splitting the engineers into several groups, some aimed at creating a tool kit of development tools for third-party software programmers, some working on applications for Lisa’s second release, and some going on to expand the machine’s networking and database capabilities. That “sustaining group,” says Rosing, will keep Lisa viable, make it smaller and faster in the future, and keep the product up to date.

Other engineers and designers are going into two new advanced research teams for hardware and software development. “The more creative ones are getting loose now. They’re going to do some really wild thinking. We’ll create an atmosphere, try not to interfere, not expect anything from them, and if we manage it right, something neat’s going to happen – we just don’t know what,” Rosing says.

by Rachael Wrege

Rachael Wrege is West Coast editor of Popular Computing.