John Page-1986

John Page

John Page

Born in London, England on September 21, 1944, John Page began working with computers as a teenager in London, and has continued to work in the computer field for over twenty years, his entire professional career.

In 1970, Page joined Hewlett-Packard. He provided technical support for HP for four years in London, Geneva, and other parts of Europe. In 1974 he moved to Cupertino, California, the headquarters of Hewlett-Packard, to manage worldwide technical support for the HP 3000 computer. Later, he moved into research and development in software, where he developed the Image Database Management System. While with Hewlett-Packard, Page studied artificial intelligence at Stanford University and did his postgraduate work in computer science.

Page left Hewlett-Packard in 1980 and teamed up with Fred Gibbons and Janelle Bedke to start Software Publishing Corporation. Working out of his garage, Page developed Software Publishing’s first product, which later became PFS: FILE. The PFS series now includes over six programs on all facets of information management. John Page is vice president of corporate research and development for the Software Publishing Corporation.

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 Page to share with us a sample of his source code to reproduce in the book, he refused, saying the request seemed to him “a crazy idea. Architects would publish examples of the churches and museums they’ve built, not blueprint fragments.” He thought a code sample would be relatively meaningless to the reader. Instead he suggested we list his many achievements and contributions to the computer world. It was this remark, more than any other, that exemplified Pages 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.

INTERVIEWER: What led you to develop the PFS: FILE program and the PFS line of software?
PAGE: When I was transferred to the Hewlett-Packard factory in California that makes the HP3000, I got heavily involved in software. There I began my work with Image, a database-management program that runs on the HP 3000. It is the most widely installed database-management system on mainframes and minicomputers.
After I’d spent a lot of time at Hewlett-Packard on database-management systems, I was struck by how much they were tailored to programmers rather than end users. That was all right at the time because companies wanted a development tool more than a product for users. But as I watched the development of personal computers, I saw that it would be feasible to create a database-management system that was genuinely usable by ordinary people. Then I began toying with the idea of such a project.
Hewlett-Packard wasn’t interested in personal computers at the time, much less software for them. I met up with Janelle Bedke and Fred Gibbons, with whom I later began the company. We discussed the project and decided to look for a software publisher. We couldn’t find one. But once we realized the software business was booming, we knew there was an opportunity to start a company, so we founded SPC. We developed a business plan that told us the amount of growth and market penetration we could expect. Once we finally made a decision to go ahead with the company, I had a vehicle to develop software ideas that had been in my head for about a year, the PFS series of 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: Why was PFS written in Pascal?
PAGE: Don’t forget the PFS program is the most long-lived program on the market now that VisiCalc is gone. Back then, five years ago, there was no C, so it was a choice between BASIC, Assembler, or Pascal. BASIC was just not it. I didn’t want to hack the whole thing out in Assembler–it would take too long. So I needed a high-level language that had some muscle to it. Pascal was the only choice. Remember, too, this was before the invention of the IBM PC, so the only machine on the market worth considering was the Apple II, and Pascal was the only program language that met my needs on that machine.
We’re switching to C as we develop new versions because it is a better development language than Pascal. But Pascal hasn’t been bad to us, certainly not as bad as the program nerds believe. I think you can only be 5 or 10 per cent more productive in C than in Pascal.
INTERVIEWER: You said PFS was extremely difficult to develop. How long did it take to design and write?
PAGE: It took me about eighteen months to design and write FILE and Report. I did it primarily on my own, although I had some help at the end.
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: Were other database programs coming out then?
PAGE: At the time, we were quite worried that Stoneware DB Master would give us a run for our money. But we got around the problem by segmenting the market–causing DB Master to be perceived as a high-end product, too complicated for people to use. It’s funny how our fortunes have differed over the years.
INTERVIEWER: Did you have any idea PFS would be the big success it turned out to be?
PAGE: I had no idea. What I tend to do in life is work out my goals, and once they’re set, I never re-examine them, or think about how hard it is, or whether it’s still worth doing, or whether it will be successful. I just go about my tasks with tunnel vision. I did that with FILE. When it began to sell, I was shocked. I thought, “My God, it worked. Look at that.”
INTERVIEWER: Do you still program?
PAGE: It’s still fun, but I don’t program as much as I’d like to. For the morale of the company, you can’t get too involved in the projects or in the programming. In a bigger company, people require leaders who know everything but not so much that the people who work for them feel inadequate and unneeded. Company employees need to feel ownership of what they’re doing and have psychological ownership of the ideas they’re implementing, otherwise they’re not motivated.
I often wonder what it must be like at Microsoft, because somebody at the head of the company is technically very dominant and well known. I wonder whether he has a negative effect on the morale of the software people in the company. I also wonder if having someone keep control puts a cap on a company’s growth potential. When the company ultimately gets to the size where the founder can’t do it all, others must be ready to take ownership and lead it the way he would have. At SPC, we are trying to get out of the limelight to set the stage for more growth later.
INTERVIEWER: Did you find it difficult to make the transition from being a computer programmer to running a huge company?
PAGE: The transition was very gradual because I’ve managed people for about twenty years. If you want to know the truth, the hard part was going from being the manager back to being a programmer. Before we started the company, I was accustomed to being in charge of a lot of people at Hewlett-Packard. When I went back to programming, I was forced to rely purely on myself. That was a shocker. It was kind of frightening–I wondered if I could still write programs. But it’s like riding a bike–you don’t ever forget; you just pedal off into the sunset.
INTERVIEWER: Since now you don’t do the programming yourself, how do you go about hiring good programmers?
PAGE: Companies need people who are true architects–people who can see beyond the basic tools to understand what should be built, who understand which technical things to take advantage of and how. For instance, a clever engineer who knows that memories will get incredibly large will sit down and ask what it means in terms of the design. What assumptions have I been making because I thought memory was scarce? How do I challenge the old ideas and sweep them away? How do I develop a different design that reflects a different way of looking at things? A company must have those people working for it.
Companies also need people who can write lumps of code for the grand architecture–people who are just good mechanics. What needs to be done is very well specified and can be given to anyone straight out of school with a bachelor’s degree in computer science. They’ll probably do alright. The question then becomes how to get the right balance of these two kinds of people.
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, documenting every step, unless the program is so big that it has to be done by more than two or three people.
Some systems, like designing a program to control the space shuttle, require a hundred programmers. Then you must have the discipline to break the structure into pieces so it all works. It’s possible to overstructure a small program and understructure a big one–you have to match the techniques to the size of the problem. That’s the way I do it.
INTERVIEWER: What about the programmers who didn’t have a hand in the design; how do you get them to work on a project?
PAGE: They may be disappointed. But you tell them at the beginning they must accept the absence of design input as a condition of working on the project. Fortunately, you find programmers who are fairly new to the game and want to be apprenticed to a good, high-level designer. It gives them a way into the industry and a path to follow to meet their own goal of designing something themselves.
INTERVIEWER: How do you manage a team working on a program?
PAGE: When a team is first assigned a project in our company, they have a lot to learn when doing things the SPC way–we think about a problem in a way that makes our product distinctive from others. I coach them on those principles from the beginning. I don’t tell them how to design, but rather try to teach the process I’d use to design. In other words, I try to educate them. I try to impart skills that will be useful to them forever. At times they’ll come up with things I don’t like, but then sometimes they don’t like the way I do things, either. We find the first programs a team builds have a few stumbles in them. But we deliberately go through that pain because I want to have people in the company who can carry the future stages of growth so we don’t get ulcers. It’s working out very well. We’ve got teams in the company working on their third product and they’re very, very good. They do a better job than I would. I find myself learning things from them; I get a real kick out of that.
INTERVIEWER: What is distinctive about the way SPC thinks about problems? Are there certain techniques or rules that programmers must follow?
PAGE: There are no basic principles except that you must know your customer, know the machine, and design the very best product for that customer and that machine.
You must understand the customers and what they want. Then you can design the correct product for them. The program may range from one that appears very simple, like PFS: FILE, to one that appears extremely complex, like a compiler. The first you design for an ordinary user, the other for a programmer or engineer. I don’t tolerate software engineers who only want to work on the more complicated programs. First, I regard that attitude as immature. A good architect takes as much pleasure in designing a small gazebo as designing a museum; each has its own challenge. Second, I think the real challenge is to design software that is simple on the outside but complex on the inside. People who don’t want to take that challenge puzzle me because to me it’s a very fascinating challenge.
INTERVIEWER: In the years you’ve worked in the computer field, you must have developed some impressions about how computers have changed over time.
PAGE: Computers are stuck in a rut because nothing new has happened in quite a while. The market has sucked us into overly complicated systems and the fault is mostly IBM’s. All the “new” features being installed are borrowed from minicomputers and mainframes. Each successive generation of the IBM PC is more complicated and harder to use than the last. The PC is fast regressing to being a minicomputer and IBM may even be successful in turning it back into a mainframe. The old complexities are coming back and the elegance is being washed out. Even the poor old Macintosh is being battered because it doesn’t have all the things that managers of management-information systems love. Macintosh designers will probably be forced to put all those complexities into the Mac, too. It’s sad that such things will probably happen sooner or later.
The net result is that personal computers are becoming more popular with people in large corporations who used to use mainframes. They’re beginning to embrace the personal computer but still trying to treat it as if it were a minicomputer. It’s not; it’s a giant personal calculator and we’ve lost sight of that.
INTERVIEWER: Do you think this trend toward complexity will continue?
PAGE: I hope not. I’ve got a feeling the personal computer will develop in two directions. There will be personal desktop business computers, which use all the same tools the mainframe required, like COBOL and all that horrible stuff. MIS managers are still programming in COBOL, just the way they did twenty years ago. If you try to give them anything at all innovative, they just say, “No. Make life simple. I want my dear old COBOL language.”
I’m also optimistic that the industry will return to making proper personal computers that people will be able to use, like the original Apple. They will be lower in price, have more power, and be easier to use. We’re derailed right now. Developing that true personal computer will breathe some life into the whole industry.
INTERVIEWER: How do you develop programs to keep pace with the changing consumer?
PAGE: You can take two directions to adjust a product to a changing market. One kind of growth is driven by the computer and its technology. You find new applications for the computer even when they diverge from the applications you began with. That kind of growth produces quite different needs from the ones you started out with. For instance, if you diversify into typesetting, you suddenly realize personal computers are great for typesetting. It will require software that’s grossly different from what you had originally developed, and you must make it tremendously functional to make it sell.
The other kind of growth is driven by the changes in your customers’ experience. As they become more aware of what the computer can do for them, their demands increase but their desire for complexity doesn’t. They want the new programs to do more but to stay simple. Our challenge is to satisfy that need because that’s the kind of growth we’ve chosen. I also think you must satisfy consumer needs to advance the state of the art; for example, making a program more functional without increasing its complexity. It costs us intellectual effort, but that’s when we make genuine advances. Unfortunately, the industry is infatuated with complexity and wants that complexity to show for some perverse reason.
INTERVIEWER: So you think the industry as a whole is technology driven rather than market driven?
PAGE: Right. They want the technology almost for show. It’s a bit like those expensive stereos–the more you pay, the more lights and knobs it has. It’s lunacy if you talk to a real user like the wife of the guy who buys it. You will find those gadgets just confuse the hell out of her. I bet if you could fingerprint the controls to see which ones are actually touched, you’d find that only three of the ninety are ever used. Nobody knows what the others do and no one touches them because the stereo works without them.
People are that way about programs, too. They’ll buy a gross, poorly designed word-processing program because they want to write letters or reports. But it’s full of controls nobody ever touches or wants. The trick is to get around that infatuation with technology. Unfortunately, because SPC deliberately hides the technology from the user, we are often regarded as a company not dedicated to sound technology. It’s annoying, too, to have worked so hard to hide the complexity and then get dinged by the trade because the program does not appear complex.
INTERVIEWER: How can you go about hiding the complexity?
PAGE: I’ll give you an example. In PFS Report, when you want a nice, calm report, you simply point to the four items you want in your report: the company’s name, address, total sales, and salesman’s name. The program searches through the database to find the width for the biggest column. Then it applies a heuristic routine which calculates the width ratio of intercolumn space to margins. The heuristic routine in the program is a complicated devil. It tries different things until it comes out with a “pleasingness” quotient on each one, ranks them, and chooses. This makes the report look aesthetically balanced, with the same margins on both sides and not too narrow, and the columns not too far apart.
The program uses a vertical-tabulation scheme to ensure the report is centered vertically on the page. The ratio strikes a balance between looking nice and fitting the data. We try to wriggle the data around in different layouts until it looks right on the page. These reports look just great 99 percent of the time and even the 1 percent are perfectly usable. The net result is that most people get nice looking reports just by specifying the items without having to think about layout.
Less sophisticated report writers require the user to specify the width of each column and where to put it on the paper. They force the user to think out how wide the name column is. The user may make a big guess–he can’t imagine a name longer than, say, twenty-five characters. Sure enough, there is one and it gets chopped off. The user expends a great deal of energy on making a decision about where to put things on the paper, and the result is horrible because they don’t quite visualize that it will look lopsided.
But here is the real “grabber.” The programs that are more difficult to use make a selling point out of that difficulty. They turn it into a feature: The user of a complex system can specify exactly where the columns go, whereas PFS puts them where it wants. The truth of the matter is that almost anybody who uses the more complex program changes the report five times before it looks just right. Or else they put up with a rotten-looking report. I question if that’s productive. The design problem becomes an issue of control versus productivity. You can have either high productivity or a great deal of control. That’s the trade-off programmers and users find themselves making all the time.
INTERVIEWER: It sounds as though it takes so much more time to develop a program that’s easy to use. How can you afford to do it?
PAGE: We do it because it benefits the user. That separates us from our competition. We build programs with automatic transmissions, which are harder to design than programs with manual transmissions. But it’s what our customer wants. We’ve got over two million programs out there, so we believe in making that extra investment because it also benefits us.
INTERVIEWER: How do you keep coming up with new ideas for programs?
PAGE: I wonder about that myself sometimes, but the real answer is staying in touch with the customers. I want the raw data and I want to interpret it myself. So periodically, at a quiet point in the day, I go through our owner-registration cards and call people at random. I ask them why they bought our product and what they’re using it for. People are incredibly shocked by the personal attention, but they will usually tell you quite a lot about what they’re doing with the product.
We watch the competition closely but we’re not seduced by industry group-think. We go to a number of conventions and meetings where our compatriots aren’t present. We like conferences that aren’t strictly centered around the computer industry but where computers are likely to be discussed. Investment conferences usually involve people from multiple disciplines–the semiconductor industry, hardware, software, and distribution. We try to visit dealers through our adopt-a-dealer plan. Everyone’s point of view goes into forming the mosaic of the industry.
Luck also plays a role. The name Software Publishing Company is very misleading because we don’t publish software. But almost anybody who’s got a program they want marketed sends it to us. So we see hundreds of new ideas from all over the country.
The biggest source of ideas comes from within the company. We use our own products–in fact we require our employees to use our products as much as possible because we want the feedback on their successes and failures. With 200 employees using our programs, we get a lot of data. And of course, people in the lab come up with their own ideas too.
INTERVIEWER: Do you interact with other programmers much?
PAGE: We try to spend time with software people because there are people out there who come up with good ideas. But surprisingly, we don’t interact much. There are some very clever people out there. But what’s odd about most programmers is that often they know the skills but haven’t figured out what to do with them. They tend to get together at conventions and talk until the early hours of the morning about listings or things like that. My response is total boredom. I think, “Well, great, that’s interesting but that’s not the meaning of life.”
There aren’t very many places where you can go to meet the people who are concerned with solving problems in the way I am. I find it stifling that I keep meeting builders and never architects. I wish there were a way to meet people who are designers in disciplines other than computers–aerospace, building construction, or engineering. I know lots of parallels can be drawn, though I don’t know what they are. It would be fun to pull together a meeting like that some day.
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.
INTERVIEWER: In what particular fields will computers develop?
PAGE: I see two significant areas that are still ripe for development in the next ten to fifteen years. One will be to get personal computers back on track and make them genuinely personal–the size of a book and $300. That will happen within two years.
The second area is communications. Right now, the way information is moved about is crude–slow, cumbersome, and expensive. Better ways are beginning to happen because of the competition and new technology. The breakup of AT&T is interesting from this point of view.
INTERVIEWER: What impact will computers have on communications?
PAGE: Communications will be faster and cheaper. Information is only useful if you can get it, and right now you can’t. I don’t think people realize how poorly informed they are. Once they realize the many possibilities, they won’t believe they ever lived without complete information.
Access to information will make a profound difference in our lives. For example, you will be able to communicate by digitized voice. Remember the messages you left for me the first time you called? You got my answering machine, which is a computer. Your voice was digitized and stored on disk in a computer that serves the entire building. I can forward your message to somebody else, and I can alter those messages and forward them from my home. I just dial into the system using the push-button phones. Without computers, that would not be possible. Soon we’ll have a home version that will cost about $300–answering machines will actually be able to talk to each other. That’s the scary part.
INTERVIEWER: What kind of information do you think we’ll have access to in the future?
PAGE: Let me give you an example of what could be available. Let’s say you want to go some place in Europe for your vacation. You want good drinking water, a nice hotel on the beach with a lap pool, and hang gliding nearby. How on earth would you find out all those things? You might find the good hotel near a beach in travel brochures, but they probably don’t mention the things that interest you most, like hang gliding and a lap pool. Unless you happen to see a photo, you have virtually no information on which to base your vacation decision. So you end up going back to the same vacation spot each year because you can’t find a new place that’s any better. There are many other examples and tons of information we don’t have about almost every aspect of our lives.
INTERVIEWER: Do some of these information resources exist today?
PAGE: Yes. For example, I’m a flier. My ability to fly has been enhanced 20 to 30 percent because I can log onto the weather service and get briefings off my computer. The other way to get the weather is much less efficient. I call the weather service and I may be put on hold for half an hour. If I do get through, I may not hear the weather correctly or I may make a mistake copying it down. I just type in my request on my computer and there it is–fast and accurate. And funny thing–I have better information than the controllers do. It’s actually better because I tap straight into the National Weather Service in Boulder, Colorado, whereas they get their weather information through some antiquated system the federal government can’t afford to update. I still have to phone in my flight plans, but that will change soon so I can file them on line.
INTERVIEWER: Why do you think so many programmers are into flying airplanes for recreation?
PAGE: One reason is that programmers who are fairly successful have the financial resources to fly. Second, flying is an engineer’s discipline because it involves manipulating complexity, which is something engineers love to do. Programmers also love to tame complexity and flying is extremely complicated, so it’s a fun thing to master. Finally, flying is like programming. A good pilot gives the passenger a flawless, boring ride, while a good programmer gives the customer a flawless, boring experience on their computer.
INTERVIEWER: Do you have other interests or pursuits?
PAGE: I’m building a house, I play guitar, and I like swimming, not for its own sake, but for the exercise.
INTERVIEWER: It doesn’t sound like you’re a workaholic.
PAGE: No, the only time I get to be one is when I’m doing something very specific and I get that tunnel vision I mentioned earlier–I haven’t done that in a while. In my role as a leader, I find I can’t work long hours. Leadership is an interpersonal activity that’s done during normal working hours. It is also incredibly draining. It takes a lot out of you without giving anything back. You see results indirectly in the growth of the people around you, the projects coming out of the company, and the company’s success as a whole. It’s fun to watch, but there’s no direct joy of accomplishment as there is in programming. As a result, I find I can’t stay at work too long. I have to find some time for me so I can stay balanced and not go crazy.
INTERVIEWER: As a programmer with that tunnel vision, is there a possibility of losing your balance?
PAGE: You have to say to all your relatives, “Look, I’m going to be gone from six to nine months. I’ll be here physically, but I might as well not be. I’m going to be working on this thing and I’ll be absent-minded. I want you to understand and tolerate that and I promise I’ll make it up to you when I get to the other end.” If you have loved ones it’s important to come through on that promise. Working so hard can be devastating to your marriage and to other relationships.
Some people get such a high from completing the project, they roll straight to another one. Doing that will literally burn you out. Each time you go straight to a new project, you get worse at it.
Also, while you’re working hard on a complicated program, it’s important to exercise. The lack of physical exercise does most programmers in. It causes a loss of mental acuity. It also leads to physical weakness that can heighten the feeling of disillusionment that often comes after the second or third straight programming effort. You look in the mirror and say, “God, look at me, why did I do this?”
INTERVIEWER: Why are programmers so obsessive?
PAGE: You constantly try to hold the state of the entire system you’re working on in your head. If you lose the mental image, it takes a long time to get back into that state. It’s like being an air-traffic controller who has nine planes in his mind and knows exactly where they’re all going. Distract him by asking him when his shift is over and he loses those planes–the model he had in his head. In programming, a big complicated model is very efficient once you’re in the groove. If you get out of it, you’ve got to work on it quite a while to get back in.
INTERVIEWER: Do you have a programming routine?
PAGE: Personally, I do my best work in the morning. I like to get up very early, when it’s quiet, and program. In fact, I try to do whatever requires concentration in the morning. I try to schedule meetings for the afternoons when my mental activity is not what it should be. I can talk alright, but I’m too tired to do creative problem solving at night. I’m useless from 6:00 p.m. until the next morning.
INTERVIEWER: What process do you go through when you program?
PAGE: I sit down and work out what I want the program to do. Then I mentally map out the components. I tend to zoom in first on the pieces where I think I’ve got problems and try to understand them. This looks hard, that looks hard and these other pieces are just normal files and old hash tables. Once I’ve dealt with the hard parts in isolation–maybe by writing a little program just to prove out some theory–I have a level of confidence about the whole program. I have pieces that are either a piece of cake or very difficult, but I know how I’m going to handle them all. Then I can go about structuring the program before I start implementing it.
I have to believe that what I want to do is achievable, otherwise I can be very distracted. I’ve seen some immature programmers who are so frightened about reaching the end goal, they just zoom in on some piece of the program and just start writing. They back into the program from a relatively minor position.
Once I’ve sketched the structure, I work on each piece in turn and define the interfaces between them. I don’t like to have a nagging feeling that I’m designing something but don’t know if a crucial component can be built. It gives me the willies, stops me from having the confidence level to proceed vigorously on the project.
INTERVIEWER: If a certain part of it doesn’t work, do you ever scrap the whole thing and start over?

PAGE: I get excited when I’ve worked hard and begin to see why nobody’s built that piece before I worked on it. If I can solve it, I can do something everyone thought was impossible. That gets my adrenaline going and my heart rate up. I just love it. I get like a dog with a bone–I will not put it down. I think about it driving around, swimming up and down, and in the shower. I just tease this problem to death until I find a way to solve it using some technique that maybe nobody’s thought of. Eventually, of course, if it turns out to be totally intractable, I will give up. But often, if I think about it long and hard enough, I’ll find a way around the problem. It may not be an elegant solution and it might not conform to all the rules of computer science, but to heck with that if it works.
I’ve always said computer science isn’t really a science because you’re not actually discovering anything about the physical universe–but that is only half true. Sometimes the solution to a problem just clicks into place like it had always been there and I uncovered it. I examine it and find it to be perfect. It’s weird.
Take the design of PFS: FILE. I remember sitting down and producing about 4 or 5 designs radically different from each other. Some of them used a relational approach. Some used a natural-language approach. I reminded myself of the criteria I was looking for. I was looking for a way to design a program that could be extended to be a family of programs–report writers, word processors, and graphics programs. They needed to have a strong family resemblance and they couldn’t surprise anyone about the way they worked. At the same time, the program had to be functionally complete. It had to do everything I wanted it to do, and be simple and easy. I synthesized ideas and tried different approaches to the design. Some worked in some areas quite well and in other areas they didn’t. Each design met all the different criteria to a different degree. Then suddenly, it’s as if I stumbled across the one that met all the objectives.
Sometimes, after I create a very good program, I feel as if I discovered it. After I’m done, I look at it and think I had to do it that way. It’s almost as if I had no control–the solution happens to me. There was no other way. Those feelings are a sign I’m onto something. Yes, discovery is the way to do it, but it doesn’t happen very often.