Ray Ozzie

Sketched portrait of software architect Ray Ozzie, renowned for creating Lotus Notes and collaborative computing platforms.

From his days in the 1980s working at Software Arts and Lotus to build VisiCalc, Lotus 1-2-3, and Lotus Notes, Ozzie has continued to build and innovate, pioneering “collaborative” software. He served in the role of CTO and Chief Software Architect for Microsoft and was responsible for launching Microsoft Azure. Currently he runs a software company, Blues Wireless. Founded with a clear mission: to make secure, scalable IoT connectivity simple and accessible for every developer. The inspiration for Blues traces back to 2011, when Japan’s devastating tsunami led to the Fukushima nuclear disaster. In response, Ray Ozzie joined a global team of scientists and engineers who volunteered to develop a way to monitor and share radiation levels in affected areas. Within weeks, they created portable devices called Radnotes- making it freely available to the public.

Excerpts from the 1985 Interview in the Book

Ray Ozzie is a young, bright, enthusiastic fellow. We met at Lotus’s new building, though Ray now runs his own business, Iris Associates, which contracts with Lotus. Being in business for himself has been his goal for his entire career. He is emphatic about giving a lot of credit and appreciation to his wife, Dawna Bousquet, who has the patience and understanding to put up with his long, arduous hours. His deep-set eyes, and fine brown hair brushed back off his forehead, coupled with his trim beard, give Ozzie a European look. In his friendly, outspoken manner, Ray Ozzie talked for hours about his programming career, from working the PLATO system when he was in college, to writing Symphony for Lotus, to starting his own company. He had many words of advice for beginning programmers, as well as insights into the future directions of computer software.
INTERVIEWER: Are there techniques for producing good programs?

OZZIE: I believe in a rigorous structure, very consistent and clean. I also believe in highly modular and layered software, and very liberal use of both numbers of files and directories. If you’re forced to build pieces separately, then the interfaces stand out more, requiring you to formalize them. When many people work on a program, it’s very important to establish, early in the project, global error-handling, argument-passing, and subroutine-naming conventions (even though everyone may not agree with them). I feel, however, that you should never tell others how to comment their code, how to use braces, or how to indent code. When you’re working in somebody else’s module, though, you’d better use his or her conventions. It’s part of learning to work with others.

The environment for the exchange of ideas should be open. Design sessions should be allowed to be very heated and intense. I have found that many good designers tend to be very opinionated and willing to stand up for what they feel is right and also know when and how to back down. Good designers do not have the “Not Invented Here” syndrome.

INTERVIEWER: You mentioned a minute ago that you prefer people who are well-seasoned. What did you mean by that?

OZZIE: To be well-seasoned you must have worked on a variety of tasks. The best thing you can do after college graduation is work on something intensely for a year or so and then move on to a totally different area in computer science. For example, you might start in operating systems, and then go to networking, graphics, compilers, or databases to get acquainted with different areas. You’re more marketable and more useful in the long run as a general programmer. Many people right out of school lack the breadth of knowledge and experience that is necessary to do significant high-level product design and development independently. A well-seasoned programmer is a generalist, is well in tune with his own abilities and lifestyle, has the ability to think abstractly, can work well with others, and is both self-motivated and well-motivated.

Excerpt 1:

INTERVIEWER: What did you do at Software Arts?

OZZIE: I started out working on the Radio Shack TRS-80 Model 3, on a language interpreter, laying the groundwork for implementation of TK!Solver. I was only there for a few weeks when they brought in a new machine for VisiCalc development—the IBM PC. I couldn’t believe the security. The rooms were locked, and we couldn’t remove the manuals from the room. The machine obviously was a prototype. After experimenting with it for a few days, I knew that I wanted one.

INTERVIEWER: Did you think that eventually everyone would want one?

OZZIE: Absolutely. Well, I thought at least programmers would want them. At the time my market awareness wasn’t highly developed. I was still basically a hacker. If IBM came out with a microcomputer, it would mean prices would drop and computers would become more affordable. It would mean programmers like me would no longer be dependent on mainframes. I was pretty excited about the IBM PC because I felt that it was the first micro powerful enough to compile a program I was working on. I could edit and compile a program, link, and run a test cycle[…] “When we first got a hard disk, it was a dream come true. I could just sit in my own office and work to my heart’s content. The documentation was atrocious, and uncovering any technical information was just about impossible, but I was too happy to care about that. Even if it was slower, working on the microcomputer was better.

I’m enthusiastic about personal computers because younger people with programming in their blood won’t have to fight and play politics to get mainframe machine access as we did. I hope parents and schools recognize what a wonderful resource PCs are. I would love to see computer centers made available for kids who want to play but can’t afford machines of their own.

Excerpt 2:

INTERVIEWER: How do you give the end user what she or he wants?

OZZIE: First we try to make a profile of who we think will use the product. Then we try to roughly estimate what percentage of the total users will use each feature, so that we have an educated guess about which attributes will be used the most. We try to spend the most time refining features used by the highest percentage of users. If there is an obscure function that’s only used by some small fraction of the users, we don t expend as much effort on the design of that function. Only after a product is shipped do we really know if our user profiles were correct.

…I think fewer people should be shooting for the moon, and more people should be finding a niche.

INTERVIEWER: Do you ever hear from the users?

OZZIE: Oh yes. There are lots of stories there. It’s fun to get a report from somebody who has used your product daily for a long time… My most amazing experience, though, was a phone call I got right after I started Iris, from a surgeon who was using Symphony for real-time data analysis during open heart surgery. It is sobering to think that someone was lying on an operating table, potentially relying upon my program running properly. It reminds one of the real responsibility to the end users.

Excerpt 3: