Seibel: Have you ever pair programmed—sat down at a computer andproduced code with another person?

Armstrong: Yeah. With Robert, Robert Virding. We would tend to dothat when both of us were kind of struggling in the dark. We didn’t reallyknow what we were doing. So if you don’t know what you’re doing then Ithink it can be very helpful with someone who also doesn’t know whatthey’re doing. If you have one programmer who’s better than the other one,then there’s probably benefit for the weaker programmer or the less experiencedprogrammer to observe the other one. They’re going to learnsomething from that. But if the gap’s too great then they won’t learn, they’lljust sit there feeling stupid. When I have done pair programming withprogrammers about the same ability as me but neither of us knew what wewere doing, then it’s been quite fun.

Then there are what I might call special problems. I wouldn’t attempt themif I’ve got a cold or I’m not on good physical form. I know it’s going to takethree days to write and I’ll plan a day and not read email and start and it’sgonna be four hours solid. I’ll do it at home so I know I won’t beinterrupted. I just want to do it and get into this complete concentratedstate where I can do it. I don’t think pair programming would help there. Itwould be very disruptive.

Seibel: What’s an example of that kind of problem?

Armstrong: Figuring out bits of a garbage collector—it’s the imperativecoding—where you’ve got to remember to mark all those registers. Ordoing some lambda lifting in the compiler, which is pretty tough—yourelabel all the variables and then you’ve got four or five layers of abstractdata types all messing around and frames with different stuff in them andyou think, “I’ve got to really understand this, really think deeply about it.”You want to concentrate.

I vary the tasks I do according to mood. Sometimes I’m very uninspired so Ithink to myself, “Ah, who shall I go and disturb now.” Or I’ll read someemails. Other times I feel, right now I’m going to do some hard codingbecause I’m in the mood for it. You’ve got to be sort of right to do thecoding. So how’s that going to work with two people? One of them is justnot in a concentrating mode and wants to read his emails and things.

Seibel: You did do a kind of serial pair programming with Robert Virding,when you passed the code back and forth rewriting it each time.

Armstrong: Yeah. One at a time. I would work on the program, typicallytwo or three weeks, and then I’d say, “Well, I’ve had enough, here you are,Robert.” And he’d take it. Every time we did this, it would come back sortof unrecognizable. He would make a large number of changes and it’d comeback to me and I’d make a large number of changes.

Seibel: And they were productive changes?

Armstrong: Oh, absolutely. I was delighted if he found better ways ofdoing things. We both got on very well. He used to generalize. I rememberonce I found a variable—I followed it round and round through about 45routines and then, out it came, at the end, never even used. He just passedthis variable in and out of 45 different functions. I said, “What’s that for?You don’t use it.” He said, “I know. Reserved for future expansion.” So Iremoved that.

I would write a specific algorithm removing all things that were notnecessary for this program. Whenever I got the program, it became shorteras it became more specific. And whenever Robert took my program itbecame longer, adding generality. I believe this Unix philosophy—a programshould do what it’s supposed to do and nothing else. And Robert’sphilosophy is it should be a general program and then the program itselfshould be a specific case of the general program. So he would add generalityand then specialize it.

Seibel: That seems like a pretty deep philosophical divide. Was there anybenefit to having the program go through those two extremes?

Armstrong: Oh yes. Every cycle it improved. I think it was a lot betterbecause of that. And probably better than either of us could have done onour own.

Seibel: Can you talk about how you design software? Maybe take exampleof something like OTP.

Armstrong: OTP was designed by me and Martin Björklund and MagnusFröberg. There were just the three of us did the original design. We metevery morning at coffee and had a long conversation—about an hour to twohours—and we covered the white board in stuff. I’d take loads of notes—Iwrote all the documentation immediately and they wrote all the code.Sometimes I’d write a bit of code as well. And when I was writing thedocumentation I’d discover, I can’t describe this, we have to change it. Orthey would run into me and say, “Nah, it doesn’t work; this idea we had thismorning, because of this, this, this, and this it doesn’t work.” At the end ofthe day we either got to the point where we got all the documentation andall the code or enough of the code and enough of the documentation thatwe knew it was going to work. And then we called it a day.

Some days it didn’t work so we said, “OK, we’ll do it again tomorrow.”There wasn’t enough time to do a second pass in a day. But about one passin a day worked fine. Because it gives us about two hours to discuss it in themorning, about two hours to write the documentation or code it up. And ifyou spent four hours really thinking hard, that’s a good day’s work. So thatworked very, very well. I don’t know how long we worked like that for. Tenweeks, twelve weeks, something like that. And then we got the basicframework and then we had more people. We’d specified thearchitecture—now we could start growing it. We’d get three or four moreprogrammers in.

Seibel: And then how did you divvy up the work for those new folks?

Armstrong: Well, we knew what were prototypes and what were finalversions. I’ve always taken the view of system design, you solve the hardproblems first. Identify the hard problems and then solve them. And thenthe easy problems, you know they’ll just come out in the wash. So there’s abit of experience there in classifying them as easy and hard. I know IP failoveror something like that is going to be fairly hard. But I know that parsinga configuration file is going to be easy. In the prototype you might just havea configuration file that you read. You don’t syntax check it—you don’t havea grammar. In the production version you might do it in XML and have acomplete grammar and validate it. But you know that that’s a mechanicalstep to do that. It will take a competent programmer several weeks, orwhatever time it takes. But it’s doable, it’s predictable in time, and thereshouldn’t be any nasty surprises on the way. But getting the communicationprotocols right, and getting them working properly when things fail, that Iwould do in a small group.

Seibel: So in this case you wrote the documentation before, or at leastwhile, the code was being written. Is that how you usually do it?

Armstrong: It depends on the difficulty of the problem. I think with verydifficult problems I quite often start right by writing the documentation. Themore difficult it is, the more likely I am to document it first.

I like documentation. I don’t think a program is finished until you’ve writtensome reasonable documentation. And I quite like a specification. I think it’sunprofessional these people who say, “What does it do? Read the code.”The code shows me what it does. It doesn’t show me what it’s supposed todo. I think the code is the answer to a problem. If you don’t have the specor you don’t have any documentation, you have to guess what the problemis from the answer. You might guess wrong. I want to be told what theproblem is.

Seibel: Is the documentation you write at this stage internal documentationthat another programmer would read or documentation for the user?