| A Personal History of Power |
|
By Bob Prichett When I was eight years old my dad brought home our first computer. It didn’t have any software that I recall, but it had the BASIC programming language built-in, and my dad explained that you could program it do whatever you wanted. This was the coolest thing – a machine you could program to do anything you wanted. All you had to do was tell it!I quickly learned that while you could theoretically write a program to do anything there were a lot of practical obstacles. Every idea I had ran into some limitation. The machine didn’t have a big enough screen, couldn’t show colors, was too slow, didn’t have enough memory, etc. Every programming project was an exercise in scaling the vision down to the limits of the technology. The first Bible software program I ever saw was for the Apple IIe. It delivered the entire King James Bible with a simple search program. The only problem was that everything was in upper-case – another limitation of the technology. Limited as it was, I was fascinated with the idea of Bible software. A few years later I found a plain-text copy of the KJV text (one book per file) on a computer bulletin board system. (Back when the Internet was the exclusive domain of universities and the government, BBS’s were how computer hobbyists exchanged messages and files.) I downloaded a few books and the accompanying search program and quickly found myself facing yet another technological limitation. With the speed of my dial-up connection it would take days to download all the books of the Bible. And once I had them downloaded the program that came with them could only search them slowly, using a "brute-force" algorithm that compared every character of every file for matches to my query. I determined to write my own Bible search program, applying the best technology I could to the vision of fast and friendly Bible software. I used a very efficient algorithm that I found in a programming magazine to increase the speed and a toolkit of user interface components I’d previously written to make a friendlier interface. My new program was faster and looked nicer than the one I’d downloaded, but it was still a very simple tool. It didn’t live up to my vision of a great Bible software package. In the following years I kept looking for technology that would allow me to write a better Bible software program. I collected algorithms and articles and thought about ways to squeeze the large text of the Bible into limited memory. I wrestled with "speed versus space" tradeoffs and discussed the problem with other programmers. In 1991 I found a partner who was interested in writing Logos Bible Software with me. For months we wrote code every night and weekend, breaking only for our day-jobs and to take meals together where we dreamed about all the great things our software would do someday. Frequently I would visit a large technical library and look for ways to implement the features we were dreaming of. We devoured programming books and magazines and talked with other programmers, always looking for ways to push the technology envelope so that we could implement more of our ideas. This need for new technology to implement our vision continued for years. As our programming project turned into a business our vision for the software grew. And as the vision expanded so did the search for new technological solutions that would enable us to deliver it. In some cases the search was for new algorithms, in other cases we were simply waiting for desktop systems to catch up in speed so that the features we designed would perform at an acceptable speed. In one discouraging case we disabled a powerful new feature before we ever shipped it because it was just too big for then-current systems. Starting Over Again In early 1998 we outlined the plans for the Libronix Digital Library System – the biggest and boldest vision in our corporate history and a completely new platform for Logos Bible Software. Keeping only the capability of reading our existing electronic books we otherwise started over, designing a system of abstract interfaces to modular components that could, theoretically, be expanded to do almost anything. Of course experience had taught me that compromises would have to be made. As beautiful as our abstract system was, there was no way it would actually run on the technology available to us and our users. From the beginning I knew we would have to hack-up the actual implementation with optimizations and "special case" code to stay within our limitations. As we implemented the system, though, we were surprised to find that our computationally-expensive, large, abstract system was actually fitting quite well within our technology limits. During the development cycle we also upgraded our computers and software tools and found that the things we expected would be difficult or even impossible to do were getting easier every day. The ugly hacks we’d resigned ourselves to needing weren’t necessary. We never took the shortcuts we thought we’d take. As we neared completion we started giving demonstrations of the system to people inside and outside the company. In the past this necessary step was always very frustrating. No matter how much input you solicit at the beginning of a project, when you’re almost done and users can actually see and test it they come up with all kinds of feature requests and ideas that simply can’t be done. The architecture is set in place, the code is almost complete, and there’s no way a major new feature can be added. This round of testing began just like all the others. The programmers showed the product, the users asked for little fixes and big new ideas, and the programmers agreed to the little fixes and said no to all the big new ideas. And then something different happened. The programmers thought about the big new ideas and realized that some of them could be done quite easily within our modular framework. So they tried a few, including the ones they were sure would run just too slow. But they weren’t hard to fit in. They didn’t run too slowly. They all worked. Crossing the Line he development of the Libronix DLS crossed a very special line – a line that I believe is being crossed in many technology product lines today. The line divides product development into two different eras. Before crossing the line the most difficult part of product development is fitting your vision within the limits of your technology. After crossing the line the most difficult part is expanding your vision to take advantage of all your technology. In the early days of Logos Bible Software no product shipped with every feature we dreamed. Many of those dreamed of features were technically infeasible if not impossile to implement. Almost every "blue-sky" feature dreamed of in the planning of the Libronix DLS was implemented, often with capabilities beyond our hopes. In the case of those that were not implemented we’re confident that they could be and that they would work well. They are held back by marketing limitations or, more often, by a lack of specific vision for them. The feature was dreamed up at a time when we didn’t really believe it could be done, and we haven’t yet thought through the details of the user interface, the marketing, and the interaction with the rest of the system. This doesn’t mean that every feature that’s been requested has been implemented, or even that everything runs as quickly as we’d like. It means that features are now constrained by time, money, or market circumstances, not technology, and that any speed issues will be addressed sooner by the relentless march of Moore’s Law (computer power-for-price doubles every eighteen months) than by a new algorithm. New Challenges In the past few years I’ve found that my reading, research, and conversations have changed. Instead of searching for new algorithms and acquiring new technology I’m looking for new ideas and new designs. I’m talking to fewer programmers and more customers. I’m focusing less on "how to do it" and more on "what to do." I’m no longer shoehorning a simple or obvious vision into a small technology "box". Today I’m looking for a vision big enough to push the edges of the box. The old joke at the end of an impressive technology demo was "But can it make coffee?" Today the answer is yes. The technology required to have Logos Bible Software make you a cup of coffee is inexpensive and easily implemented. The hard part now is to decide if it should and if so what the interface looks like. I’m excited about crossing the line. I’m looking forward to building products that are more focused on user needs than technology limitations. I enjoy saying "Yes, we can do that." We’re going to need help, though, to grow the vision, and to break out of the mindset of simple steps and incremental improvements. We’re going to need users to stop waiting to see what tools the technologists can provide and to start asking for the impossible. Because we’ve crossed the line and right now the impossible is possible. |
| < Prev | Next > |
|---|
