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.
Next page: Robert Carr, Framework