C. Wayne Ratliff

Sketched portrait of database pioneer C. Wayne Ratliff, the creator of dBASE II for early microcomputers.

Whatever was Ratliff’s fascination, whether race cars, spacecraft, boats or betting on football he always brought brilliant software to the endeavor. He was a member of the NASA Viking Program flight team when the Viking spacecraft landed on Mars in 1976. In 1978 Ratliff wrote Vulcan, a database application to help him make picks for football pools. He tried selling Vulcan, his first database program by himself but didn’t get traction, so he licensed the software, renamed dBASE to Ashton-Tate and the program became a widely used tool for businesses. He was so busy with work at Ashton-Tate, he never used the software for its original purpose; to wager on football games.

Currently retired, Ratliff spends time sailing and studying mathematics. He has worked on computer systems for use in competitive sailboat racing. He resides in Los Angeles.

Excerpts from the 1985 Interview in the Book

I went to an Ashton-Tate research center in Glendale to talk with C. Wayne Ratliff, the creator of dBASE. He welcomed me into his large office, where we sat down at a round table and talked at length about his accomplishments and insights about programming. Ratliff is a tall westerner who has an air of independence and a comfortable manner. After more than fifteen years in the computer industry, he still abounds in fresh enthusiasm. Unlike many programmers who tire of the actual writing of source code, Ratliff still thrives on working at all phases of program development every day.
INTERVIEWER: So programming swept you away from car design?

RATLIFF: Computers themselves got me away from car design. Before I completed my degree, I got a job with Martin Marietta in Denver. I was a computer. My job title was computer. Other people have programmed computers, but I have been one.

INTERVIEWER: You’d better explain that.

RATLIFF: Well, it was a throwback to the earlier days of aerospace engineering. When people had, for instance, a differential equation to solve, they had an army of people with Monroe calculators, and each person would work on a separate segment of the equation. One person would do a certain group of adds, then hand their paper to the next person to do the multiplies, and so on. They called those people computers. Computers then were more like administrative assistants, except that they did engineering-related jobs instead of administrative jobs. Since I could program, that’s how they used me. Then I got drafted during the heat of the Vietnam war in 1969.

INTERVIEWER: What experiences led you to your Vulcan program?

RATLIFF: After the army, I was a Martin Marietta employee and a contractor at Jet Propulsion Laboratory. I was with the Viking project and wrote the data-management program for the Viking lander, called MFILE. That was in 1976, around the time that I became interested in designing and experimenting with natural language, so I bought an IMSAI 8080 8-bit computer kit and put it together. It took a year to put the thing together, mostly waiting for parts. I had to solder more than 2,200 joints. Of course, if I could have bought it assembled for the same price, or even close, I would have. Once I had put it together, all I had was a computer. Nothing was included except IK of memory. You had to keep buying things, such as a keyboard. I had already spent $1,000 for the kit, then I had to spend another $159 for a keyboard. Eventually I ended up spending about $6,000.

INTERVIEWER: Were your experiments with natural language the foundation for dBASE?

RATLIFF: dBASE started, oddly enough, from football games. I was in a football pool where you picked the winner and then a point spread. I’ve never known that much about football. It was the motivation to win, rather than the game itself, that interested me. I thought that if I devoutly applied myself to the mathematical process, I could win. The way to do that was to look at all the statistics. Every Monday morning the newspaper publishes all the statistics for the weekend games—it takes up at least a double page. About four or five weeks into the season, I had an entire room completely layered with newspaper! I was trying to figure out how to pick a winner by going from paper to paper, a horrible process, and I decided it was too much to handle without a computer. Well, one thing led to another, and within a week, I’d totally forgotten about football. I had decided that the world needed a natural-language database manager.

INTERVIEWER: Why do you think dBASE is so successful?

RATLIFF: There was a tremendous amount of luck. But dBASE was also the right program in the right place at the right time, and that’s not totally luck—that’s design. The fact that it is a language, as well as a database manager, has turned out to be enormously important. dBASE caught people’s imaginations because it’s very open-ended. The way I’ve programmed all my life is as a toolmaker. When I compare myself, even ten years ago, with other programmers, I see that I was trying to generalize to a large extent; they were trying to write programs that would solve a specific need.

Their programs would frequently be delivered much sooner than mine would be, but mine would have longer lifetimes. Once the specific need went away, their programs were dead, they had to be rewritten each time the needs changed. I always wrote in such a way that the program could solve a family of problems, rather than just a single one. dBASE was different from programs like BASIC, C, FORTRAN, and COBOL in that a lot of the dirty work had already been done. The data manipulation is done by dBASE instead of by the user, so the user can concentrate on what he is doing, rather than having to mess with the dirty details of opening, reading, and closing files, and managing space allocation….

If you write a program well, it’s very elegant; it sings, it’s well built. I enjoy it from an engineering point of view, just like a well-built car, a well-built bridge, or a well-built building. Everything about it seems in balance, tuned.

INTERVIEWER: Can you elaborate on this feeling for balance and elegance?

RATLIFF: Balance takes many forms. The code should be crisp and concise. You should be able to explain any module in one sentence, and things should be in alphabetical order, if possible. Just from a visual view of indentation, it shouldn’t go off the edge of the paper at any point. It shouldn’t have one “if” that’s huge and an “else” that’s small. Everything should be balanced everywhere. Balance is the key word.

Interview Excerpt: