John Page

“John Page is a trim, fit, slightly boyish-looking man with kind eyes, a warm smile, and a slight English accent. He wore a blue shirt with the collar buttons undone and gray slacks. Page escorted me through the comfortable California-style, redwood-beamed offices of Software Publishing into a large, vacant conference room. There Page relaxed into a state of reflection and analysis on his approach to programming and running a software business.

When I asked John to share with us a sample of his source code to reproduce in the book, he declined… more than any other, that exemplified Page’s approach to programming: He has the ordinary user in the forefront of his thoughts as he goes about the task of developing software. It is the end result, not so much the means used in getting there, which fascinates and motivates Page. As he explained, complicated programs are far easier to write than straightforward programs.”

“INTERVIEWER: How did you want to make PFS different from other programs on the market at the time?

PAGE: What I thought was missing was an application ordinary people could use, much like a telephone or car. The goal was to design a program that would be as easy to learn as an appliance. It was an interesting design trade-off because it meant I should pursue maximum understandability rather than maximum performance and functionality. It’s a bit like the phone system, which isn’t very sophisticated on the outside. You dial the number, the phone rings, and you talk to people. That’s all it does. That’s not much, right? But to make that happen, a great deal of complex technology has to be marshalled behind the scenes. Designing PFS worked in the same way as the phone system: simple on the outside, backed by sophisticated technology. In designing PFS, I stumbled over an odd software design principle: Complicated programs are far easier to write than straightforward programs—the exact opposite of what you’d expect. It’s easy to write complicated programs because you reflect the complexity back onto the user; you force the user to make all the hard decisions. For example, suppose the user wants to know how many blocks there are in the file. You set it up so he can find out himself. What he does with the information, God knows. With a very simple program, however, the designer has to figure out the answers himself. It was fascinating to move from developing very complex software primarily for programmers to developing programs for Joe Everyman.

INTERVIEWER: What presented the biggest problem in developing the program?

PAGE: Back then the biggest problem was shoehorning the whole thing into a 48K Apple and making it run at a reasonable speed. The Pascal was interpreted, which meant its performance left a whole lot to be desired. And once the program was finished, it was extremely slow, so I isolated all of the areas where the performance bottlenecks occurred and recoded those in Assembly language. That fixed the problems, and I got the program to perform on target, but recoding something in Assembler with no debugging tools was just a horrible experience. The other problem was a strategic business problem. Just at the time we came out with PFS, a 48K Apple was regarded as a very large configuration: In fact, it was the top-of-the-line, while a 32K machine was typical. There was a 64K Apple but the extra 16K board cost $550. Remember that back then computers really were personal; people spent their own money on these machines, and a $500 to $600 board was a significant purchase. We had to make a decision. There was no way we could get the programs to run on 32K. We had already put FILE and Report into two programs because they wouldn’t fit together in the 48K Apple II. It’s still two programs although not for much longer. Would we be successful in requiring a 48K machine? More memory was risky because it cut down the market size. I lay awake many nights wondering if we would get away with it.

INTERVIEWER: What is the difference between writing a program by yourself and writing it with a team of people?

PAGE: If the product requires four or five people, then you go about it differently than if you write it by yourself. I believe very strongly that one person, certainly no more than two, should do the design and high-level structure. You get a consistency and elegance when it springs from one mind. You can be misled by trying to make it fun for everybody and have a committee design the thing. That is absolutely fatal. So I have a very small team working at the definition stage, and then I expand it to implement the design, if necessary. The bigger the team that is required to implement the design of a program, the more disciplined you have to be about breaking the structure into manageable pieces and defining the interfaces. You don’t have to do many structured-program reports. Then you must have[…]”

“INTERVIEWER: What role do you think computers will play in the future?

PAGE: They will always play an absolutely central role in everything. Information is a fundamental fabric of the universe. Information about things is almost as valuable as the things themselves, and computers process information. I was reading a very interesting article in Business Week about the power of information. People are beginning to realize how important having good information is.

One man who has billions of dollars invested said he honestly believed the information about his investments was more valuable in real dollars than the investments themselves. Think about it—that means that information is a resource or a raw material as valuable as gold. Think about how careful you would be in using it, processing it, and protecting it. That is just what computers do so well. The prediction that computers will permeate every aspect of society will absolutely come true.”