Whereas he does most of his composition on his guitar. He plays stuff and fools around with it, maybe plunks around at the piano a little bit, runs through it again. And he never writes anything down. He’ll write down the chord sequences, maybe, if pressed, and I guess at some point he writes down the words. But he doesn’t come at composition kind of from the symbol-based mindset at all.

So some people go that way, some people don’t. If I was going to draw lessons from it—well again, I’m kind of an elitist: I would say that the people who should be programming are the people who feel comfortable in the world of symbols. If you don’t feel really pretty comfortable swimming around in that world, maybe programming isn’t what you should be doing.

Seibel: Did you have any important mentors?

Deutsch: There were two people One of them is someone who’s no longer around; his name was Calvin Mooers. He was an early pioneer in information systems. I believe he is credited with actually coining the term information retrieval. His background was originally in library science. I met him when I was, I think, high-school or college age. He had started to design a programming language that he thought would be usable directly by just people. But he didn’t know anything about programming languages. And at that point, I did because I had built this Lisp system and I’d studied some other programming languages.

So we got together and the language that he eventually wound up making was one that I think it’s fair to say that he and I kind of codesigned. It was called TRAC. He was just a real supportive guy at that point for me.

The other person that I’ve always thought of as something of a mentor is Danny Bobrow. He and I have been friends for a very long time. And I’ve always thought of him as kind of a mentor in the process of my career.

But in terms of actually how to program, how to do software, there wasn’t anybody at MIT. There wasn’t really anybody at Berkeley. At PARC, only one person really affected the way that I did software, and he wasn’t even a programmer. That was Jerry Elkind, who was the manager of the Computer Science Lab at PARC for a while.

The thing that he said that made a profound effect on me was how important it is to measure things; that there’ll be times—maybe more times than you think—when your beliefs or intuitions just won’t be right, so measure things. Even sometimes measure things you don’t think you need to measure. That had a profound effect on me.

When I want to do something that’s going to involve a significant amount of computation or significant amount of data, one of the things that I always do now is measure. And that’s been the case since I was at PARC, which was starting about 35 years ago.

Seibel: You were the only person I contacted about this book who had a really strong reaction to the word coder in the title. How would you prefer to describe yourself?

Deutsch: I have to say at this point in my life I have even a mildly negative reaction to the word programmer. If you look at the process of creating software that actually works, that does something useful, there are a lot of different roles and a lot of different processes and skills that go into achieving that end. Someone can call themselves a programmer and that doesn’t tell you very much about what set of skills they actually bring to bear to that process.

But at least the word programmer is pretty well established as covering a pretty wide range. “Coder” is strongly associated with the smallest and most narrowly focused part of that whole endeavor. I think of coder, in relation to the process of producing software that actually works and does something useful, as being maybe slightly above bricklayer in the process of constructing buildings that actually work.

There’s nothing wrong with being a coder. There’s nothing wrong with being a bricklayer, either. There’s a lot of skill that goes into doing it well. But it represents such a small corner of the whole process.

Seibel: What is an encompassing term that would work for you? Software developer? Computer scientist?

Deutsch: I have a little bit of a rant about computer science also. I could make a pretty strong case that the word science should not be applied to computing. I think essentially all of what’s called computer science is some combination of engineering and applied mathematics. I think very little of it is science in terms of the scientific process, where what you’re doing is developing better descriptions of observed phenomena.

I guess if I was to pick a short snappy phrase I would probably say software developer. That covers pretty much everything from architecture to coding. It doesn’t cover some of the other things that have to happen in order to produce software that actually works and is useful, but it covers pretty much all of what I’ve done.

Seibel: What doesn’t it cover?

Deutsch: It doesn’t cover the process of understanding the problem domain and eliciting and understanding the requirements. It doesn’t cover the process—at least not all of the process—of the kind of feedback loops from testing to what happens after the software has been released. Basically “software developer” refers to the world within the boundaries of the organization that’s developing the software. It says very little about the connections between that organization and its customers or the rest of the world, which, after all, are what justifies the creation of software in the first place.

Seibel: Do you think that’s changing? These days there are people advocating trying to connect earlier with the customer or user and really making that part of the software developer’s job.

Deutsch: Yes, XP certainly does that. I’m not a big fan of XP, and it’s for two reasons. XP advocates very tight coupling with the customer during the development process on, I guess, two grounds. One is that this results in the customer’s needs being understood and met better. That may well be true. I don’t have firsthand knowledge of it but I’m a little wary of that because the customer doesn’t always know what the customer’s needs are.

The other reason that XP, I think, advocates this tight coupling with the customer is to avoid premature generalization or overdesign. I think that’s a two-edged sword. Because I’ve seen that process go astray in both directions: both premature generalization and premature specialization.

So I have some questions about XP in that respect. What happens after the project is “done”? Is it maintainable? Is it supportable? Is it evolvable? What happens when the original developers have left? Because XP is so documentation-phobic, I have very grave concerns about that.

That’s an issue I’ve had with a number of people who are very much into rapid prototyping or any form of software development that doesn’t treat it as engineering. I seriously question how well software not built from an engineering point of view lasts.

Seibel: Can you give an example of when you’ve seen generalization or specialization go awry?

Deutsch: When I was in the peak years of my career, one of the things that I did extremely well, and I can’t claim that I did it in a completely systematic way, was to pick the right level of generality to cover several years’ worth of future evolution in directions that might not have been completely obvious.

But I think in retrospect the one example of premature specialization was the decision in Ghostscript, at an architectural level, to use pixel-oriented rather than plane-oriented representation of color maps. To use bitmaps and to require the representation of a pixel to fit in a machine long.

The fact that it used a chunky rather than planar representation meant that it turned out to be very awkward to deal with spot color—where you have printers that may, for specific jobs, require colors that are not the standard CMYK inks. For example silver, gold, or special tints that have to be matched exactly.