Seibel Peter. Coders at Work
Подождите немного. Документ загружается.
L Peter Deutsch
425
Seibel: As you made the progression from writing small pieces of code to
building big systems, did you still write small pieces of code the same way
and just add a new perspective about bigger systems, or did it actually
change the way you did the whole thing?
Deutsch: It changed the way I did the whole thing. The first significant
programs I wrote would be the ones on the UNIVAC at Harvard. The next
little cluster would be the work that I did on the PDP-1 at MIT. There were
really three different programs or systems that I think of dating from that
era, 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 work
on the operating system for Jack Dennis’s weird modified PDP-1. And I
wrote a text editor for Dennis’s PDP-1.
Those three systems I still wrote basically monolithically. The difference
from my old programs on the UNIVAC was I had to start doing data-
structure design. So that was the first big shift in what kind of programming
I was doing.
I was starting to be aware of what I would call functional segmentation but I
didn’t think of it as having any particular significance. I was aware that you
could write certain parts of the program and not have to think about other
parts of the program while you were doing it, but the issues about
interfaces, which really become paramount as programs get big, I don’t
recall those being of concern.
That transition happened with my the next big cluster of work, which was
the work that I did at Berkeley, mostly as an undergraduate, on Project
Genie: the 940 timesharing system and on the QED text editor. And I
wrote an assembly-language debugger but I don’t remember much of
anything about it.
The piece that had the most system flavor to it was the operating system.
It’s not fair to say that I wrote the whole operating system; I didn’t. But I
essentially wrote the whole kernel. This was done in assembly language.
We’re talking about programs that are getting to be a little larger here,
probably on the order of 10,000 lines of assembler. It had a process
Download at Boykma.Com
L Peter Deutsch
426
scheduler. It had virtual memory. It had a file system. In fact, it had several
file systems.
There, there were more complex questions of data-structure design. The
one that I remember is there was an active process table. And there was a
question as to how to design that and how the operating system should
decide when a process was runnable or not—that kind of thing. There were
structures for keeping track of the virtual memory system. But some issues
of interface started to emerge. Not within the operating system itself,
because the operating system was so small that the kernel was designed
essentially as a single piece, as a monolith.
But there were two important areas where issues of software interface
started to emerge. One of them was simply the interface between user
programs and the kernel. What should the system calls be? How should the
parameters be laid out? I know that in the first few versions of the 940 TSS,
the basic operations for reading and writing files were the equivalent of the
Unix
read and write calls, where you basically gave a base address and a
count. Well, that was all very well and good, but a lot of the time that
wasn’t what you wanted. You basically wanted a stream interface. And in
those days, we didn’t have the concept that you could take an operating-
system facility and then wrap user-level code around it to give you some
nicer interface in the way
getc and putc get built on top of read and write.
So what we actually did was in later versions of the operating system, we
added operating-system calls that were the equivalent of
getc and putc.
The other place where issues of interface started to show up were—again,
based on the MULTICS mode—from the beginning we had a strong
distinction between the kernel and what today we would call the shell. This
was early enough in the development of operating systems that we didn’t
realize that you could, in fact, build a shell with essentially no special
privileges. The shell was a user-mode program, but it had a lot of special
privileges. But there were some issues about what facilities the kernel had
to give the shell—what things the shell should be able to do directly and
what things it should have to make kernel calls for.
We saw interface-design choices just emerging from the task. That was the
point in my career at which I dimly started to become aware that interfaces
Download at Boykma.Com
L Peter Deutsch
427
between entities really needed to be designed separately, that the interfaces
between them were also an important design issue.
So responding to your question about whether the way I programmed in
the small changed as I started to work with larger systems, the answer is,
yes. As I built larger and larger systems, I found that when sitting down to
write any piece of code, more and more the question I would ask myself
first is, “OK, what’s the interface between this and everything around it
going to look like? What gets passed in? What gets passed out? How much
of a task should be on which side of an interface?” Those kinds of questions
started to become a larger and larger part of what I was dealing with. And
they did affect the way that I wrote individual smaller chunks of code, I
think.
Seibel: And this was a natural consequence of working on bigger systems—
eventually the systems get big enough that you just have to find some way
to break them apart.
Deutsch: That’s right. In that sense I agree that software is fractal in that
decomposition is an issue that happens at many different levels. I was going
to say I don’t think that the kinds of decomposition at bigger grains are
qualitatively the same as the kinds of decomposition that happen at smaller
grains. I’m not sure. When you’re doing decomposition at a smaller grain
you may not be thinking, for example, about resource allocation; when
you’re doing decomposition at a larger grain you have to.
Seibel: Have you worked with people who, in your opinion, were very
good programmers, yet who could only work at a certain scale? Like they
could work well on problems up to a sort of certain size but beyond that,
they just didn’t have the mentality for breaking systems apart and thinking
about them that way?
Deutsch: I’ve worked with programmers who were very smart but who
didn’t have experience at larger-scale programming. And for Ghostscript, I
did have some pretty serious disagreements with two of the engineers who
were brought into the team as it was getting handed over to the company
that I started. Both very smart and hardworking guys, both experienced. I
thought they were very good programmers, good designers. But they were
not system thinkers. Not only were they not used to thinking in terms of
Download at Boykma.Com
L Peter Deutsch
428
the impact or ramifications of changes; they to some extent didn’t even
realize that that was an essential question to ask. To me the distinction is
between people who understand what the questions are that you have to
ask in doing larger-scale design and the people who for whatever reason
don’t see those questions as well.
Seibel: But you think those people—when they’re not trying to be the
architect of a whole system—do good work?
Deutsch: Yeah. The two engineers that I’m thinking of both did really great
work for the company. One of them was working on something that was
large and rather thankless but important commercially. And the other one
redid some substantial chunks of my graphics code and his code produces
better-looking results. So these are good, smart, experienced guys. They
just don’t kind of see that part of the picture—at least that’s my take on it.
Seibel: Are there particular skills that you feel made you a good
programmer?
Deutsch: I’m going to give you a very new-age answer here. I’m not a new-
age kind of guy generally speaking, although I went through my period of
really long hair. When I was at what I would consider the peak of my
abilities, I had extremely trustworthy intuition. I would do things and they
would just turn out right. Some of that was luck. Some of it, I’m sure, was
experience that had simply gotten internalized so far down that I didn’t have
conscious access to the process. But I think I just had a knack for it. I know
that’s not a very satisfying answer but I truly believe that some of what
made me good at what I did was something that was just there.
Seibel: In your days as a precocious teenager hanging out at MIT, did you
have had a chance to observe, “Wow, this guy’s really smart but he doesn’t
know how to do this thing that I know how to do.”?
Deutsch: No, I didn’t. Well, OK, I do remember when I started rewriting
the text editor on Dennis’s PDP-1; I must have been 15 or 16. The original
code had been written by one or two of the guys from the Tech Model
Railroad Club group. Those were smart guys. And I looked at the code and
I thought a lot of it was awful.
Download at Boykma.Com
L Peter Deutsch
429
I would not say it was a difference between me and the people I was
working around. It was a difference between the way I thought code should
be and the code that I saw in front of me. I would hesitate to generalize that
into a statement about the people.
I’ve always been really comfortable in what I would call the symbolic world,
the world of symbols. Symbols and their patterns have always just been the
stuff I eat for lunch. And for a lot of people that’s not the case. I see it even
with my partner. We’re both musicians. We’re both composers. We’re
both vocal performers. But I come at music primarily from a symbolic point
of view. I do a lot of my composition just with a pencil and a pad of paper.
The notes are in there but I’m not picking them out on the piano. I hear
them and I have a plan.
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.
Download at Boykma.Com
L Peter Deutsch
430
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
Download at Boykma.Com
L Peter Deutsch
431
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.
Download at Boykma.Com
L Peter Deutsch
432
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.
Download at Boykma.Com
L Peter Deutsch
433
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.
If you look at a pixelized color image there are more or less two ways of
representing that in memory. You can represent it in memory as an array of
pixels where each pixel contains RGB or CMYK data for the spot on the
image. That’s typically the way display controllers work, for example.
The other way, which is more common in the printing industry, is to have
an array that contains the amount of red for each pixel and then another
that contains the amount of green for each pixel, then another that contains
the amount of blue, etc., etc. If you’re processing things on a pixel-by-pixel
basis, this is less convenient. On the other hand, it doesn’t impose any a
priori constraint on how many different inks or how many different plates
can go into the production of a given image.
Seibel: So if you have a printer that can use gold ink, you just add a plane.
Deutsch: Right. This certainly is not common in consumer-grade printers
or even typically in office printers. But in offset printing it is relatively
common to have special layers. So that was one area of insufficient
generalization.
So that’s an example where even with a great deal of thought and skill I
missed the boat. It doesn’t illustrate my point well; in a sense it undermines
my point because, in this case, even careful foresight resulted in insufficient
generalization. And I can tell you exactly where that insufficient foresight
came from—it came from the fact that Ghostscript was basically done by
one very smart guy who had no acquaintance with the printing industry.
Seibel: Meaning you.
Deutsch: Right. Ghostscript started out as strictly a screen previewer for
previewing PostScript files because there wasn’t one and PDF didn’t exist
yet. If I was going to draw a moral from that story, it’s that requirements
Download at Boykma.Com
L Peter Deutsch
434
always change, they always are going to at least attempt to change in
directions you didn’t think of.
There are two schools of thought as to how you prepare yourself for that.
One school of thought, which I think is probably pretty close to the way XP
looks at it, that basically says that because requirements are going to change
all the time, you shouldn’t expect software to last. If the requirements
change, you build something new. There is, I think, a certain amount of
wisdom in that.
The problem being the old saying in the business: “fast, cheap, good—pick
any two.” If you build things fast and you have some way of building them
inexpensively, it’s very unlikely that they’re going to be good. But this school
of thought says you shouldn’t expect software to last.
I think behind this perhaps is a mindset of software as expense vs. software
as capital asset. I’m very much in the software-as-capital-asset school. When
I was working at ParcPlace and Adele Goldberg was out there evangelizing
object-oriented design, part of the way we talked about objects and part of
the way we advocated object-oriented languages and design to our
customers and potential customers is to say, “Look, you should treat
software as a capital asset.”
And there is no such thing as a capital asset that doesn’t require ongoing
maintenance and investment. You should expect that there’s going to be
some cost associated with maintaining a growing library of reusable
software. And that is going to complicate your accounting because it means
you can’t charge the cost of building a piece of software only to the project
or the customer that’s motivating the creation of that software at this time.
You have to think of it the way you would think of a capital asset.
Seibel: Like building a new factory.
Deutsch: Right. A large part of the sell for objects was that well-designed
objects are reusable, so the investment that you put into the design pays
itself back in less effort going down the road.
I still believe that, but probably not quite as strongly as I did. The things that
I see getting reused these days are either very large or very small. The scale
Download at Boykma.Com