Some early programmer names are familiar to even the most novice of software developers. You may never have seen a line of code written by Bill Gates, or written any application in BASIC (much less for the Altair). But you know Gates' name, and the names of a few others.
That's a darned shame, because the early microcomputer era (we didn't uniformly call them "personal computers" yet) had many brilliant software developers. Some of them went on to greater fame and fortune; others disappeared into the mists of history.
[ The New Type of Programmer: DevOp ]
In 1986, Susan Lammers did a series of interviews with 19 prominent programmers in a Microsoft Press book, Programmers at Work. These interviews -- many of which the author transcribed on her own website a few years ago -- give a unique view into the shared perceptions of accomplished programmers... the people who invented the tools you use today.
Lammers' book is still enjoyable on its own merits, simply because it's a bunch of very smart developers talking about their craft at a time when there were relative few wide shoulders to stand upon. In re-reading my copy, I was reminded by how raw the technology industry was, how many competing standards we had to weed through (it had been years since I saw a list of the late-1980s databases: R:Base, Paradox, Javelin, ANZA) -- and yet how soon we expected to achieve Artificial Intelligence.
I chose five of the book's programmers for this time machine, leaving the remainder's fate primarily an exercise for the intrepid reader.
[ See also: Priceless! The 25 Funniest Vintage Tech Ads ]
Here you'll learn the then-current programming opinions from Dan Bricklin (VisiCalc), Jonathan Sachs (Lotus 1-2-3), Robert Carr (Ashton-Tate Framework), Bill Gates (BASIC on microcomputers), and Charles Simonyi (Multiplan).
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.
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."
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 10,000 hours of experience much sooner, perhaps leading to proficiency in their careers earlier.
Robert Carr, Framework
Then: In the mid-1980s, the computing world was yearning for an integrated software suite, or at least all the magazines told us so. The two major choices were Ashton-Tate's Framework and Lotus Symphony. Robert Carr co-founded Forefront and developed Framework, which had a spreadsheet, word processing, database, telecommunications, and outlining, all on a floppy disk. Ashton-Tate bought Forefront in 1985, where Carr became chief scientist -- his role when he was interviewed for the Programmers at Work book. Borland acquired Ashton-Tate in 1991.
On programming in teams: "I've tried to surround myself with people who are better than I am. A lot of the people I've hired for Forefront are better programmers than I am, and I've learned a lot from them. [Xerox] ASD also showed me that great software development is largely composed of good initial design and, thereafter, a lot of very solid engineering."
On software design: "One piece of advice I had been given was to hold off programming for as long as possible. Once you get a corpus of code building up, it's hard to change direction. It sets like concrete. So I held off for as long as I could, but I couldn't hold the design in my head forever."
On managing developers: "My role is one of facilitator, drawing out the design ideas and helping the group towards a conclusion. Not my conclusion, but one evolved by the group. ...Occasionally, there will be a situation where we just can't get a consensus, so we step back and examine the time constraints, money constraints, or space constraints, and then decide from there. The original Framework process was a very iterative and evolutionary one."
On user interfaces: "Users should be able to forget that there is a program between them and their information. In fact, as they get used to the software, their minds should be filled only with the task at hand; they shouldn't have to stop and think about what command they need."
On the future of computing: "I hope we can move toward component software. Then the user will be able to replace a piece of a program with a plug-in module from a software house that knows how to do floating-point arithmetic or word processing better. This will be a trend over the next ten years. But it's a tough goal because we're talking about the interfaces between separate modules of software, one of the least understood areas in software design."