The Spreadsheet Wizards
Dan Bricklin: VisiCalc
Then: The VisiCalc spreadsheet was the original “killer app,” by which we used to mean: “This application is the reason you have to buy a computer.” I knew a mechanical engineer who snuck his Apple IIe into the office so he could run VisiCalc on business problems, when the waiting list for the Control Data mainframe was months long. VisiCalc, created by Dan Bricklin and Bob Frankston sold over half a million copies by 1983; the company that marketed it, Software Arts, imploded due to legal battles.
Dan Bricklin
On innovation: “I went to see my finance professor [with the VisiCalc prototype], who was discouraging. He looked up from his printouts and he said: ‘Well, there already are financial forecasting systems and people won’t buy micros, for example, to do real estate.’ . . . Of course, now Harvard requires you to buy a PC before you can go to their business school.”
On the evolution of programming: “People are writing their own programs. Anybody who uses a spreadsheet is writing their own programs; it’s just that the language is different now. . . . We’re just making the users do more and more of the programming themselves, but they don’t know it. Using different style sheets with Microsoft Word is doing programming; using spreadsheets is doing programming.”
On the business of software development: “There is an inherent cottage industry component to programming. . . . Any large company could have a million programmers working on some idea to produce a better one, but they don’t because it doesn’t work that way. The economics aren’t there. Sometimes the idea behind a program is one small creative effort. . . . In terms of marketing, you do need a large marketing organization. But there’s a variety of ways to do that, just like with [publishing] books. . . . If you look at the biggest sellers in the software industry, in general they were written by very few people.”
On the future of computing: “All sorts of products are developing now. People are saying, ‘What about networking, why can’t we connect this stuff together?’ What about the publication systems, like the inexpensive ones available on the Mac? And the really great ones that are available on the bigger machines, like Apollo and Sun? A few years ago, no one thought that in-house publishing was going to be a major use of computers.”
On the future of computer hardware: “The personal computer of the future should be more like a notebook. I carry my notebook around and why shouldn’t it be a computer? Well, that’s different than the PC as we know it. Computer technology is going to be used for all sorts of new areas like that. ...One way to have a computer follow you around is to miniaturize it. Why go to all the trouble to put legs on it if we can miniaturize it to the point that we can carry it on our bodies. We’re getting to the point soon where we can get a lot of computing power in a very small space.”
Today: Bricklin runs a tiny company called Software Garden whose products include Note Taker for the iPad and a video, A Developer’s Introduction to Copyright and Open Source, He also does consulting and speaking.
Bricklin spoke with me about software methodologies, programming career choices, and other issues.
Lammers asked many of the programmers, “What kind of training or type of thought leads to the greatest productivity in the computer field?” but for some reason didn’t ask this question of Bricklin. I remedied the oversight.
In many ways, he says, their needs were different. Then, you needed experience in a variety of areas, which may not be as useful today. It certainly is good to have a varied background; as Bricklin explains, “For me it was very helpful to have a background in many different languages,” since he could choose the appropriate language for the current application rather than “the one I know.” Having a range, he says, keeps you from getting stuck in one system; and when new things come about, you aren’t as lost.
But one thing is and was necessary: experience shipping a product. You should know, he says, “what it is to actually complete something and get it out the door. That’s a real important thing to learn.” Nothing beats the experience of shipping software, to take something from start to finish. You get feedback from users, and find out what you did right and wrong. It’s even better, he says, to do this with other people, from whom you can learn “what it means to get all the pieces together of the project complete enough for you to get it out the door.”
VisiCalc
Bricklin programs much the same way he did in the 1980s. “One thing I’ve always done, for many years — I know Bob Frankston did, too — you have to figure out a path through the whole thing and implement that first,” he says. And then you go back to add more. “Getting the path through is like building a scaffold. A lot more is put on [the application] before it’s a real product,” but you have the critical path in place. “It’s always building off something that’s working.”
What about his premise, in 1986, that software development was inherently a “cottage industry?” That’s still true, Bricklin says. “There still are small companies. And there are still small companies with leading companies in several [product] areas.” The best chances for this may be the “App Store” marketplace and open source. Bricklin has some successful open source projects, and he is now in the app world. “Some of what I’m doing is like what I was doing 20 years ago,” he adds.
Some products are more complex, and as a result, “The big companies do things that can only be built by a big company with many hands,” he says. “That’s always been the case and it looks like it is going to continue.”
But individuals can still do things that are worthwhile and that they can make money on. “If we forget that we’re going to lose a lot of creativity,” says Bricklin.
Jonathan Sachs, Lotus 1-2-3
Then: In 1981, Jonathan Sachs teamed up with Mitch Kapor to develop and promote Lotus 1-2-3, the software that brought the IBM PC into so many corporate offices.
On programming methodology: “The methodology we used to develop 1-2-3 had a lot to do with the success of the product. For instance, 1-2-3 began with a working program, and it continued to be a working program throughout its development. ...This was the exact opposite of the standard method for developing a big program, where you spend a lot of time and work up a functional spec, do a modular decomposition, give each piece to a bunch of people, and integrate the pieces when they’re all done. The problem with that method is you don’t get a working program until the very end.” This works fine with more than three people; they used a team approach with Lotus Jazz.
On the future of computing: “The rate of innovation is rather slow. There are only a few really new ideas every decade. In fact, people complain about the good old days of paper tape and such things, but some of the old technology was really good. And I’m not sure much progress will be made over time. . . . We’re seeing all these new processors, but a lot of the power is lost because everyone wants all the features, and that slows everything down.”
Today: Sachs is “mostly retired” these days, though he has a finger in a company called Digital Light & Color, which, since 1992, has made software for photographers. He recently has been “playing around” with Android phone software but doesn’t know yet what he’ll do with it.
Sachs was kind enough to speak with me about his current and past perspectives on programming.
I showed him the quote above about developing “a working program,” which sounds a lot like what we’d call Agile today. Does he still write software the same way?
“It works that way for me,” says Sachs. People have their own ways of working, however, and everyone has their own natural style. “I ran into a guy at Lotus, later, who would spend a long time thinking about the program. He would type in the whole program in the final form and debug the whole thing,” Sachs explained. “There are some virtues to that. You have anticipated difficulties, you don’t get stuck on dead ends.” But, he says, development takes a lot longer and there are things you don’t realize until you start working on the program.
One thing that has changed from the “frontier days” is that today typically a developer works on only a little tiny piece. “There was a day when you could know everything there was to know about a given computer,” he says. In his previous positions pre-Lotus, “I got to write computer languages and databases and scientific software. By the time I got to write a spreadsheet I knew all the pieces.”
Reading other people’s code is still an important way to learn, because “When programmers read each other’s code you can see if someone is really good or not,” he says.
Sachs agrees with Malcolm Gladwell’s Outliers theory that you have to spend 10,000 hours doing something to get really good at it. “That’s really true of programming, and I’ve been doing it a long time,” says Sachs. But this generation’s programmers started much earlier, he points out, and whole generations of kids will get their 100,000 hours of experience much sooner, perhaps leading to proficiency in their careers earlier.