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

So some people go that way, some people don’t. If I was going to drawlessons from it—well again, I’m kind of an elitist: I would say that the peoplewho should be programming are the people who feel comfortable in theworld of symbols. If you don’t feel really pretty comfortable swimmingaround 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 nolonger around; his name was Calvin Mooers. He was an early pioneer ininformation systems. I believe he is credited with actually coining the terminformation retrieval. His background was originally in library science. I methim when I was, I think, high-school or college age. He had started to designa programming language that he thought would be usable directly by justpeople. But he didn’t know anything about programming languages. And atthat point, I did because I had built this Lisp system and I’d studied someother programming languages.

So we got together and the language that he eventually wound up makingwas one that I think it’s fair to say that he and I kind of codesigned. It wascalled 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 isDanny Bobrow. He and I have been friends for a very long time. And I’vealways 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’tanybody at MIT. There wasn’t really anybody at Berkeley. At PARC, onlyone person really affected the way that I did software, and he wasn’t even aprogrammer. That was Jerry Elkind, who was the manager of the ComputerScience Lab at PARC for a while.

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

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

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

Deutsch: I have to say at this point in my life I have even a mildly negativereaction to the word programmer. If you look at the process of creatingsoftware that actually works, that does something useful, there are a lot ofdifferent roles and a lot of different processes and skills that go intoachieving that end. Someone can call themselves a programmer and thatdoesn’t tell you very much about what set of skills they actually bring tobear to that process.

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

There’s nothing wrong with being a coder. There’s nothing wrong withbeing 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? Softwaredeveloper? Computer scientist?

Deutsch: I have a little bit of a rant about computer science also. I couldmake a pretty strong case that the word science should not be applied tocomputing. I think essentially all of what’s called computer science is somecombination of engineering and applied mathematics. I think very little of itis science in terms of the scientific process, where what you’re doing isdeveloping better descriptions of observed phenomena.

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

Seibel: What doesn’t it cover?

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

Seibel: Do you think that’s changing? These days there are peopleadvocating trying to connect earlier with the customer or user and reallymaking 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 fortwo reasons. XP advocates very tight coupling with the customer during thedevelopment process on, I guess, two grounds. One is that this results inthe customer’s needs being understood and met better. That may well betrue. I don’t have firsthand knowledge of it but I’m a little wary of thatbecause the customer doesn’t always know what the customer’s needs are.

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

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

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

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

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

But I think in retrospect the one example of premature specialization wasthe decision in Ghostscript, at an architectural level, to use pixel-orientedrather than plane-oriented representation of color maps. To use bitmapsand 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 thatit turned out to be very awkward to deal with spot color—where you haveprinters that may, for specific jobs, require colors that are not the standardCMYK inks. For example silver, gold, or special tints that have to bematched exactly.