Seibel: So is it OK for people who don’t have a talent for systems-levelthinking to work on smaller parts of software? Can you split theprogrammers and the architects? Or do you really want everyone who’sworking on systems-style software, since it is sort of fractal, to be able tothink in terms of systems?

Deutsch: I don’t think software is fractal. It might be nice if it were but Idon’t think it is because I don’t think we have very good tools for dealingwith the things that happen as systems get large. I think the things thathappen when systems get large are qualitatively different from the thingsthat happen as systems go from being small to medium size.

But in terms of who should do software, I don’t have a good flat answer tothat. I do know that the further down in the plumbing the software is, themore important it is that it be built by really good people. That’s an elitistpoint of view, and I’m happy to hold it.

Part of what’s going on today is that the boundary between what is softwareand what isn’t software is getting blurred. If you have someone who’sdesigning a web site, if that web site has any kind of even moderatelycomplex behavior in terms of interacting with the user or tracking state,you have tools for building web sites like that. And working with thosetools—as I understand it, not having used them—accomplishes some of thesame ends as programming, but the means don’t look very much like writingprograms.

So one of the answers to your question might be that over time a larger andlarger fraction of what people used to think of as requiring programmingwon’t be “programming” any more and pretty much anybody will be able todo it and do a reasonable job of it.

You know the old story about the telephone and the telephone operators?The story is, sometime fairly early in the adoption of the telephone, when itwas clear that use of the telephone was just expanding at an incredible rate,more and more people were having to be hired to work as operatorsbecause we didn’t have dial telephones. Someone extrapolated the growthrate and said, “My God. By 20 or 30 years from now, every single personwill have to be a telephone operator.” Well, that’s what happened. I thinksomething like that may be happening in some big areas of programming, aswell.

Seibel: Can programmers be replaced that way?

Deutsch: Depends on what you want to program. One of the things thatI’ve been thinking about off and on over the last five-plus years is, “Why isprogramming so hard?”

You have the algorithmic side of programming and that’s close enough tomathematics that you can use mathematics as the basic model, if you will,for what goes on in it. You can use mathematical methods and mathematicalways of thinking. That doesn’t make it easy, but nobody thinks mathematicsis easy. So there’s a pretty good match between the material you’re workingwith and our understanding of that material and our understanding of theskill level that’s required to work with it.

I think part of the problem with the other kind of programming is that theworld of basically all programming languages that we have is so different insuch deep ways from the physical world that our senses and our brains andour society have coevolved to deal with, that it is loony to expect people todo well with it. There has to something a little wrong with you for you tobe a really good programmer. Maybe “wrong with you” is a little too strong,but the qualities that make somebody a well-functioning human being andthe qualities that make somebody a really good programmer—they overlapbut they don’t overlap a whole heck of a lot. And I’m speaking as someonewho was a very good programmer.

The world of von Neumann computation and Algol-family languages hassuch different requirements than the physical world, that to me it’s actuallyquite surprising that we manage to build large systems at all that work evenas poorly as they do.

Perhaps it shouldn’t be any more surprising than the fact that we can buildjet airliners, but jet airliners are working in the physical world and we havethousands of years of mechanical engineering to draw on. For software, wehave this weird world with these weird, really bizarre fundamentalproperties. The physical world’s properties are rooted in subatomic physics,but you’ve got these layers: you’ve got subatomic physics, you’ve got atomicphysics, you’ve got chemistry. You’ve got tons of emergent properties thatcome out of that and we have all of this apparatus for functioning well inthat world.

I don’t look around and see anything that looks like an address or a pointer.We have objects; we don’t have these weird things that computer scientistsmisname “objects.”

Seibel: To say nothing of the scale. Two to the 64th of anything is a lot,and things happening billions of times a second is fast.

Deutsch: But that doesn’t bother us here in the real world. You knowAvogadro’s number, right? Ten to the 23rd? So, we’re looking here aroundat a world that has incredible numbers of little things all clumped togetherand happening at the same time. It doesn’t bother us because the world issuch that you don’t have to understand this table at a subatomic level.

The physical properties of matter are such that 99.9 percent of the time youcan understand it in aggregate. And everything you have to know about it,you can understand from dealing with it in aggregate. To a great extent, thatis not true in the world of software.

People keep trying to do modularization structures for software. And thestate of that art has been improving over time, but it’s still, in my opinion,very far away from the ease with which we look around and see things thathave, whatever it is, 10 to the 23rd atoms in them, and it doesn’t even fazeus.

Software is a discipline of detail, and that is a deep, horrendous fundamentalproblem with software. Until we understand how to conceptualize andorganize software in a way that we don’t have to think about how everylittle piece interacts with every other piece, things are not going to get awhole lot better. And we’re very far from being there.

Seibel: Are the technical reasons things that could be changed, or is it justthe nature of the beast?

Deutsch: You’d have to start over. You’d have to throw out all languagesthat have the concept of a pointer to begin with because there is no suchthing as a pointer in the real world. You’d have to come to grips with thefact that information takes space and exists over time and is located at aparticular place.

Seibel: As you made the progression from writing small pieces of code tobuilding big systems, did you still write small pieces of code the same wayand just add a new perspective about bigger systems, or did it actuallychange the way you did the whole thing?

Deutsch: It changed the way I did the whole thing. The first significantprograms I wrote would be the ones on the UNIVAC at Harvard. The nextlittle cluster would be the work that I did on the PDP-1 at MIT. There werereally three different programs or systems that I think of dating from thatera, in the early-1960s timeframe, around when I was in high school.

There was a Lisp interpreter that I built for a stock PDP-1. I did some workon the operating system for Jack Dennis’s weird modified PDP-1. And Iwrote a text editor for Dennis’s PDP-1.

Those three systems I still wrote basically monolithically. The differencefrom my old programs on the UNIVAC was I had to start doing data–structuredesign. So that was the first big shift in what kind of programmingI was doing.

I was starting to be aware of what I would call functional segmentation but Ididn’t think of it as having any particular significance. I was aware that youcould write certain parts of the program and not have to think about otherparts of the program while you were doing it, but the issues aboutinterfaces, which really become paramount as programs get big, I don’trecall those being of concern.