Fog Creek Software
Discussion Board




Pair painting

Whether it's a mural or the side of a barn, painting can be done by more than one painter. However, the painters do not work on the same area at the same time, or use the same brush.
Many or most projects, in all fields, are done by teams. This includes the arts, construction, sports, military, etc. But you almost never have two people working on the same aspect of the thing at the same time. The only exception I could think of so far is a pilot and a co-pilot. But they are not constructing or creating anything.
In many kinds of endeavors, two individuals work as a pair -- for example, athlete and coach, writer and editor, musician and conductor, etc. But they don't work on the same thing at the same time.
Only in pair programming, useless fad that it is, does this occur.
I would try it, if forced to. I can't legitimately claim to hate something I have never tried. But for the reasons listed above I predict that pair programming is not here to stay.

The Real PC
Monday, June 02, 2003

Sorry to sound pedantic, but pilot and co-pilot is not a good example, as they don't fly the plane at the same time, they take turns.

Steve Jones (UK)
Monday, June 02, 2003

Ok, well, that just supports the argument that it's hard to find an analogy for pair programming.

The Real PC
Monday, June 02, 2003

What I don't get is all the animosity and angst being read into the XP and pair programming fad.

Survival comes first. Where I live, it's really difficult to even find a suitable software development job, much less one that has "terms" that are personally suitable to any one person.

For my money: 100% pair programming is probably a really stupid idea; it's probably a fad; in my mind, putting people into a forced crucible to work intensely to each other's satisfaction isn't solving the major problem in the SW industry, which is that of defining the most suitable thing to construct. But the employer reigns supreme, no matter how stupid he/it is.

Bored Bystander
Monday, June 02, 2003

In music people often do work on the same thing at the same time. Lyricists and arrangers will have quite a bit of interplay.

Though in music, you often get to choose who you work with... Even if you hate them.

www.MarkTAW.com
Monday, June 02, 2003

I did think about the lyricist/composer team. However, this analogy doesn't work either. The lyricist and the composer are doing completely different things. Even if they work on the same song at the same time (which may not be the typical scenario anyway), they are still each doing their separate thing.

The Real PC
Monday, June 02, 2003

[the employer reigns supreme, no matter how stupid he/it is. ]

That, Bored, is what generates all the angst. Especially at a time when you can't hop jobs so easily.

The Real PC
Monday, June 02, 2003

By the way, my employer is far from stupid. So I am counting on him being disillusioned with pair programming right away.
On the other hand, other aspects of XP make sense.

The Real PC
Monday, June 02, 2003

> I did think about the lyricist/composer team. However, this
> analogy doesn't work either. The lyricist and the composer
> are doing completely different things.

"Composing" is not necessarily a one-man-show.

I played in a rock band for a brief period, and many of our best ideas were born like this:
1. Paulo is fooling around with a guitar riff.
2. Bass player listens to the loop a couple of times and gets in.
3. A couple of more loops. Drummer tries to add something.
4. Stop. Some suggestions from everyone, .e.g, "move to F instead of C", or, "make it softer here, and more aggresive there".
5. Restart. Stop. Rework. Repeat until you're either not going anywhere or you're happy with the result - for the time being, naturally :)

While this may not be a formal method of composing, it still qualifies as composing. And we'd all be involved in this process, giving ideas about other people's parts, as well as our own.

--
"Suravye ninto manshima taishite (Peace favor your sword)" (Shienaran salute)
"Life is a dream from which we all must wake before we can dream again" (Amys, Aiel Wise One)

Paulo Caetano
Monday, June 02, 2003

paulo, 

what you are talking about is called teamwork.  Programmers regularly work as part of a team.

XP/Pairing in your case would be you & the bass player trying to come up with the guitar riff.

& sharing the guitar.

just some dude
Monday, June 02, 2003

>> "Only in pair programming, useless fad that it is, does this occur. I would try it, if forced to. I can't legitimately claim to hate something I have never tried. But for the reasons listed above I predict that pair programming is not here to stay."

Pair programming does not literally mean working on the same thing at the same time.  Here's how we do it and it works fine.

I write a procedure.  You review it.
You write a procedure.  I review it.

You are stuck while coding.  I help you.
I am stuck while coding.  You help me.

You ensure I am adhering to the design/functional spec.
I ensure You are adhering to the design/functional spec.

You help me fix a bug.
I help you fix a bug.

You help me design a function.
I help you design a function

You and the other programmer have to work out a routine that enables you to work together.  You are basically a check for each-other and really do not get in each-others way.  As long as one of you isn't so proud so as to demean the other all day long, it works fine.

Anyway, this is a dead subject.  Very dead.  Dead as a door knob.

You think I'm joking.  I'm not.

AnyMouse
Monday, June 02, 2003

PP means sharing one computer.  that, to me, is working on the same thing at the same time.

just some dude
Monday, June 02, 2003

How much of programming actually involves using the keyboard.

The hard part of coding actually takes place between the ears, not at the end of the fingers.

Ged Byrne
Monday, June 02, 2003

>> "PP means sharing one computer.  that, to me, is working on the same thing at the same time."

Sharing one computer does not mean you work on the same thing at the same time.  It means taking turns as I stated earlier and you check each-others work.  The only people I have known that have not been good at pair programming were those that were socially inept (who need to be fired to begin with), those with so much pride that they cannot fathom working with someone "below" them, and those stubborn people who don't want to do anything but sit in their "own space" and do "what they do."

Anyway.  Dead as my dog.

You think I'm joking. I'm not.

AnyMouse
Monday, June 02, 2003

Pair programming involves a lot more than just using the same computer and taking turns typing.

Pair programming is about SHARING. You share ideas, you share responsibility, and you share the creative process.

I've never met a developer that was better than me in all aspects, but I've worked with several people who knew their part of the project better. By working together we can leverage each other's strengths.

I don't think pair programming works for everybody. People who are arrogant, smelly, rude, lazy, or ditzy just don't make good pair partners. If you have a good team with healthy levels of respect on all sides then I think pair programming can be good.

As far as finding analogies go... why try so hard? Analogies usually break down at some point so don't try to find one that matches pair programming exactly.

NathanJ
Monday, June 02, 2003

Sharing.  Now that's the word I was looking for.

You think I'm joking.  I'm not.

AnyMouse
Monday, June 02, 2003

AnyMouse says: >>>Pair programming does not literally mean working on the same thing at the same time.  Here's how we do it and it works fine.<<<

What you describe doesn't sound like pair programming.  The XP web site says this about PP: "All code to be included in a production release is created by two people working together at a single computer...."  With two people always at the same computer, one with the keyboard and the other looking over his/her shoulder, that sounds like working on the same thing at the same time.

What you describe sounds more like team work or collaboration.  I haven't read any complaints about that in these discussions.  However, on this discussion board and in talking with co-workers I have found several people that favor PP, but when you discuss it, you find that they are talking about collaboration, not anything like XP's PP.

mackinac
Monday, June 02, 2003


Well, I'll just say this:

Pair programming is the single biggest reason for the improvement in our product quality where I work.

Single biggest reason. End of statement.

If you don't believe, you don't believe. That's cool. Don't force it. But, for us, we'll never program singly again.

Bruce
Monday, June 02, 2003

Collaboration is fine and we don't have any where I work. I have tried collaborating by asking others questions, but there is an unspoken rule here that if you ask questions you are a novice. So no one asked me questions in return, and there was no collaboration, no discussion.
They are trying to go from one extreme to the other, and extremes usually do not work.

The Real PC
Monday, June 02, 2003

It is much closer to screenwriting, where partnerships are quite common.  The idea is that you are doing creative work which must meet an outside specification.  This is often easier to do when you have someone else in the room to help edit your ideas as they happen, rather than explore an idea to its conclusion, and then discover that it was a bad tangent.

A writing/coding partner (and I've had both) doesn't help come up with better ideas, just get bad ones killed faster.  (That may be some of the resistance.)

Contrary Mary
Monday, June 02, 2003


Interesting annecote:

Since the beginning of the project that I work on, only two developers have been "let go". Both had problems with pair programming and collective ownership of code. Neither were missed all that much by the team.

It's an anecdote, so you can't draw that much from it, but I'm beginning to believe that there is a connection between the "worth" of a developer and their willingness to pair and to accept collective code ownership.

Bruce
Monday, June 02, 2003

>>>Pair programming is the single biggest reason for the improvement in our product quality where I work. <<<

Bruce, since you are one of the few with real experience, I'd like to ask the following:

1 - Do you do PP as described by XP?  That is, two developers at the same computer working on the same thing all the time.

2 - Did you adopt the entire XP methodology for your development?  If so, what has been the effect of the other XP features on quality and how do you separate the effects of PP?

3 - What was the development environment and methodology in use before PP?

Thanks.

mackinac
Monday, June 02, 2003

People that say pair programming is a waste of time either haven't done it or are hermits.

Without pair programming: I sit in my office all day, constantly reading this forum.

With pair programming: I sit with someone else, working hard, creating good code that we both understand and can maintain.

Even without being a slacker, pair programming, in my experience, produces better code, as long as the other person doesn't smell.

Jorgenson
Monday, June 02, 2003


Some background:

I am what I call an "administrative team lead" on our product. I'm technical, but I do mostly planning (hey, someone's gotta do it).

I've worked in that capacity on 2 projects that use XP, for a total of 4 releases in about 2 years. We average one release every six months.

We do a "modified" XP. We use a many of XP's practices, with a few modifications designed to fit in with the overall corporate software development process. XP is what we call an "execution" process in that it focuses primarily on the execution of software development. We also have planning and requirements gathering processes, etc, etc.

We do pair programming for ALL new code. That is, two developers sit at the same workstation and work on the same code at the same time. Typically, one developer is the "driver" and the other is the "navigator". The driver tends to think "tactically", or about the current body of code being implemented. The navigator tends to thing "strategically" or about the implications of the current edit.

We also do test first coding, collective code ownership, a common coding standard (even if it sometimes boils down to "use the same standard as was there to begin with"), and frequent integration, all of which are necessary in order to make PP work.

In comparison with some of the other projects in our company, which have not been using agile processes for as long, we typically exhibit a much lower defect count throughout development. As a result, our "beta" periods are short and our stabilization up to release is pretty much routine.

All in all, our experience with PP is entirely positive. We "go faster" with PP and the quality of the code is better than any produced singly.

As a gross generalization, we've found that developers who don't like PP either haven't done it properly, or are developers you don't want around your project in the first place.

Bruce
Monday, June 02, 2003

>> "All code to be included in a production release is created by two people working together at a single computer...."

Exactly.

What I meant is "same time" does not mean keying in code for the same routine at the same time.

AnyMouse
Monday, June 02, 2003

AnyMouse:

You must be joking.


Monday, June 02, 2003

[our experience with PP is entirely positive]

But you don't know which XP techniques cause the improvement. Most XP ideas make perfect sense and will result in a better outcome. The one stupid idea (and I will change my mind if I ever try it and like it), pair programming, gets the credit for the success.
In scientific terms, the conclusion that PP is helpful results from a confound -- the OTHER XP techniques might be causing the improvement.

The Real PC
Monday, June 02, 2003

I thought the pilot/copilot analogy works well. One is physically guiding the plane while the other is making sure the other is doing it correctly. It adds redudancy to a situation where mistake could cost you dearly. Albeit those mistakes cost people's lives and software mistakes cost money but the redundancy can help developers avoid mistakes. Does it work in every situation? Doubtful. Does _any_ methodology work in every situation? Doubtful.

Ian Stallings
Monday, June 02, 2003


True, but you can say that about virtually any practice in any process.

Come on, this should be obvious. How much of what you think is good about your current process is based on anecdotal evidence?

At least we have some basis for our belief. We didn't pair before. We do now. Our software is better. We work just as fast, if not faster.

You are applying standards to PP that you don't even apply to your current practices.

Bruce
Monday, June 02, 2003

Ah, Jorgenson, I think you may be on to something here. You may have identified the reason some people don't want to be forced into pair programming:

"Even without being a slacker, pair programming, in my experience, produces better code, as long as the other person doesn't smell. "

After all, nobody wants to work with someone that hates them... [grinning, ducking, running]

Philo

Philo
Monday, June 02, 2003

Real PC and other Pair detractors - have you ever done ANYTHING as a team? Are you arguing that teamwork *cannot* produce superior results to the work of a single person?

My theory; once more, with feeling:
Two people working on the same software will:
a. Produce faster than one person
b. Produce fewer bugs than one person
c. Produce "cleaner" code than one person (more efficient, closer to standard spec)
d. Produce redundancy, increasing the project's bus number

The question is: Is pair programming worth it? While the coders produce code faster than 1x coder, do they produce code faster than they would individually (2x coders)? If not, does the increased quality of code produced (b, c, d) outweigh the 2x coders - 1 pair coders differential?

Philo

Philo
Monday, June 02, 2003


Philo,

The deciding factor for us is that, of the 3 "levers" available to anyone planning a software project (quality, scope, time), we are not allowed to "pull" the quality lever.

That is, we can play with the scope of a release, we can play with the time for a release, but we cannot play with the quality. That direction means the plusses of PP far outweigh any loss in efficiency absorbed by having two developers work together. For us.

Plus, I should point out that many observations of the relative speed of two developers versus a pair fail to take into consideration time spent fixing errors. Since a pair will usually produce far fewer errors than two individuals, this can represent a substantial "drag" on the single developer. In some cases, a pair may actually go faster than two individuals.

Bruce
Monday, June 02, 2003

Ian wrote: "Does it work in every situation? Doubtful. Does _any_ methodology work in every situation? Doubtful. "

Come on Ian, this isn't the place for level headed discussion!

victim, jr.
Monday, June 02, 2003

Pair programmers are going to feel pretty stupid in ten years time when we ask the question:

Whatever happened to pair programming?  Kee-riiist that was one stupid idea!

smartass
Monday, June 02, 2003

Smartass-
Seriously, what are you trying to accomplish here? There are some very talented programmers and successful business leaders saying that they've seen pair programming work, yet you seem to insist it's completely unworkable based either on:
a) your loathing of the idea of having to work closely with another professional developer
b) your liimited experience in actually doing so, extrapolating that experience to the entire IT industry.

If you want to succeed in this business, you really need to learn to put aside your prejudices and appreciate new (and old but different) ideas on their merits, and perhaps even sometimes grant "hey, maybe it works for you, but I've tried it and it's not for me" - there's no shame in that.

Just my $.02

Philo

Philo
Monday, June 02, 2003

Philo,
The confusion results from the fact tha XP probably does work very well. It includes some sensible ideas. Since pair programming is part of XP, you assume it is responsible for the success of XP. I think you should collect some data before feeling so confident.
Try applying the XP techniques minus pairing. Encourage progammers to communicate more, have a flexible and iterative design, improve communication with users, etc. But leave out the pairing and see if your results are different.
I realize I'm being skeptical about something I never tried. But that's only because it sounds really dumb.
If you said all programmers should stand on their heads for 5 minutes every hour, I would not be skeptical, because that idea makes sense to me. However, it would seem ridiculous to a lot of people and it would not work for everyone.
I mean, all kinds of strange things would work for various individuals. Why impose something that seems silly on everyone, just because it might work for some?

The Real PC
Monday, June 02, 2003

>> "You must be joking."

I'm not.

AnyMouse
Monday, June 02, 2003

Real PC - I'm not talking XP; I'm talking pairing.
To me, XP is simply the way development should work. Pairing is still up for debate.

Have you *read* my analysis of pairing any of the half dozen times I've written it? In general I don't rely on "XP Success Stories" to justify pair programming - I justify PP because it makes sense to me.

[broken record]
A proper pair *will* produce faster than a single developer. IMHO they will also produce higher-quality code. The question is "do a pair produce faster than *both* coders independently, and if not, is the quality of code they produce going to be worth the reduced kloc/day?"

Or perhaps another way of looking at it - instead of calling "checking in working code" productivity, let's define it as "written, peered, QA'd, debugged, commented, and ready for production release." I think with that metric, there's a very good chance that a good pair will outperform the two programmers working independently.

****

The reason I laughed at Pairing being set up in your shop is the way they're going about it - by dictate instead of through a rational management process with help from the developers. Also, of course, the "close the barn door after the horse is in the glue factory" approach.

Philo

Philo
Monday, June 02, 2003

Pilots don't do pair-piloting at all.

The second pilot is there to provide redundancy in case the the first pilot becomes incapacitated for any reason during flight, not to look over the other guy's shoulder.

Not bored
Monday, June 02, 2003

The more I see of pair programming, the more it seems to be a bully-boy tactic for mediocre people to exercise sway in development departments.

Note the type of places that implement pair programming, by the way. They're typically in-house departments that don't have a clue anyway. They're often coasting from fad tot fad, desperately trying to improve their software process. They need to do this because they've never discovered how to hire or retain good people.

Very much not bored
Monday, June 02, 2003

Philo: Another way in which pairing may win is by diffusing knowledge throughout a team.  Every piece of code will be understood by at least two people, and if you switch pairs often, this knowledge will spread.

And if you know the code well, you can develop faster.

A few studies have been done.  It appears that, in the short term, pairs are approximately as fast as two programmers working alone.  So even a small improvement in code quality or  knowledge diffusion could make pairing a good idea.

Of course, test-driven design and refactoring are such tremendous productivity boosters (in my personal experience) that the effects of pairing may get lost in the noise.  I've personally seen TDD & refactoring make the difference between total project failure and a smashing success.

My experiences with pairing have been very good, but I don't do it often, and I'm not very good at it yet--it's obviously a learned skill. 

J. Random Hacker
Monday, June 02, 2003

"The more I see of pair programming, the more it seems to be a bully-boy tactic for mediocre people to exercise sway in development departments."

Perhaps you've seen it used that way, but I don't believe that that's what's happened every time it's used.  There seem to be some pretty talented individuals that have done it and enjoyed the experience.

Philo

Philo
Monday, June 02, 2003

It is really frustrating when someone shoots down an idea on the basis of "well, I've never tried it and I hope I never will, because I can't wrap my mind around it working."  Well, maybe it works or maybe it doesn't, you'll never know.  I'm frustrated I wasted my time writing a couple posts on topics I thought were about improving oneself.

There are just too many discussions wasted when people refuse to believe that individuals can work on a project in a distributed fashion, with any quality.  Or that someone can write in a language that uses whitespace over punctuation.  If you only do things that others have done for millenia before you, then why bother programming?

Now as for your company, of course it's destined to fail with its experiments.  They hired consultants to tell them what anyone who reads a couple books with pictures could.  How much contempt for its employees can it have to not simply empower someone with, "I'd like you to check out this XP stuff, I know some of it will turn your gut, but try to grow great teams using it."

greg
Monday, June 02, 2003

The problem of the other person smelling is sometimes a killer, not that they necessarily smell but they could have some other social tic or habit or emotional or political opinion which gets in the way.

Or you might.

Pair programming isn't new.  Sometimes its a conversation with one typist, sometimes its turn and turn about, and sometimes its more than one computer and not in the same timezone cos you can look at the same stuff and run it and watch it fall over altogether.

I've most often done it in troubleshooting mode, in either position, driver or driven.  Debugging with another person can be a seductively cool thing to do.

If anyone waves their hand and says 'oh but that's not pair programming', tough. 

Simon Lucy
Monday, June 02, 2003

I'm 100% behind doing (Joel's words) Hard-assed-bug-fixing(R).  That's a lot different than pair programming though.  Usually only the best are involved.  Newbies or less experienced sit back in the back.  One of the best corporate experiences I had was when a couple of developers and some operations people watched me fix a hard-assed bug.  Nerdy maybe, but extreme ego gratification nonetheless.  On the other hand, imagine 8 hours a day with Arnold Poindexter.  Ugghhhh!

victim, jr.
Monday, June 02, 2003

[How much contempt for its employees can it have to not simply empower someone with, "I'd like you to check out this XP stuff, I know some of it will turn your gut, but try to grow great teams using it."]

Right, that is part of the reason I don't feel receptive. The boss said "anyone who can't work this way will be taken off the project."
I am open to pair programming as a way of sharing knowledge occasionally. I am all in favor of sharing knowledge (which no one in my department does spontaneously).
It was the way he said it. I asked him if he is convinced pair programming works and he said "no" -- he just wants to try it.

As I said, this won't affect me because I am not involved in that project. But I am apprehensive because of management's attitute. However, I can see why the boss has this attitude, since the project has dragged on so unsuccessfully. He had nothing to do with the project until now, and now he is taking it over. Maybe he has to be forceful, at least at first, in order to get the developers under control.

The Real PC
Tuesday, June 03, 2003

[The more I see of pair programming, the more it seems to be a bully-boy tactic for mediocre people to exercise sway in development departments. ]

Lol. Typical.

Actually, I see PP as almost exactly the opposite. It's a way for people to help each other up. Two brains are almost always better than one.

But, to me, the telling point in this argument is the comment above. I am so totally sick and tired of the "l33t coder with teh mad skilz" attitude of many developers. Especially since, in the vast majority of cases, this attitude is unwarranted.

I have never met a "god-like" programmer. Ever. I've met some talented people who don't think. I've met less talented people who work their asses off. I've met talented developers who do use their brains but, sadly, they are rare.

Most of those I have met realize that coding is the LEAST important factor in producing software. Here's a challenge: I get a team of average developers with the will to work together. You get a team of uber-coder prima donna's. Who's team do you think is going to get software out the door more often? And yet we cling to the idea that coding makes the project.

The Real PC is trying to argue that pair programming is not the reason for the benefits seen in teams using XP. That's certainly possible. But, while it may be possible, his reasoning is flawed.

The point is not to question pair progamming. The point is to question solo programming. Again, a reverse challenge for the Real PC: try doing exactly what you are doing now, except use pair progamming. Don't use any other XP practice. See what you get.

You accept solo programming because that's what the uber-coder, "my virtual penis is bigger than your virtual penis", l33t skillz, "programming as an art form", mentality has pushed for so many years. There's no reason for solo programming, it just is.

Bruce
Tuesday, June 03, 2003


[However, I can see why the boss has this attitude, since the project has dragged on so unsuccessfully.]

This is possibly a rude question, but how much respect are we expected to have for team of developers that are failing at what they are trying to do now, but aren't willing to try something new?

XP may not be the answer, but if what you say is true then neither is what they are doing now. At least XP offers the possibility of success. Repeating past mistakes doesn't.

Also troubling is the implied sense that the developers are just innocent bystanders on this project. They resent this new manager coming in and shaking up the team. That's fine. But then my answer would be for them to take the initiative (and the responsibility) and plot their own course out of the mess.

You think that managers like messing with teams? I can assure you that they much prefer a team that works happily and well on it's own. If a manager is seen rampaging through a project like this it is a sign that the team isn't mature enough to take care of it's own problems. I know that doesn't go over very well in this world we've built where developers are all omiscient and the rest of the organization is a bunch of bozos, but it's sometimes true nonetheless.

Bruce
Tuesday, June 03, 2003

About two and a half years ago I was involved in a little project. Well, it was a "number one priority" for the company, but the company had at least two of those at the time that I knew about. It was intended to be an XP project, but before long it faded away so that pair programming was all that was really left.

Along the way, we encountered a problem with our locking. We simply wouldn't have discovered and remedied nearly as quickly as we did without the close communication that pair programming introduces. And when early completion of the project facilitates an informal little demonstration after a board meeting, you're pretty glad you resolved an issue that could have made your service appear to stop responding entirely...

So I feel pretty good about pair programming, even apart from XP.

Adam Fitzpatrick
Tuesday, June 03, 2003

[The second pilot is there to provide redundancy in case the the first pilot becomes incapacitated for any reason during flight, not to look over the other guy's shoulder]

A copilot plays an important part in flying any plane. He/she does not simply wait for the pilot to become incapacitated. Although they do serve in this function that is not their only role. Copilots are not always subordinates and do correct mistakes made by the pilot. I'd like to think that any pilot would welcome such corrections and not take the same attitude that programmers take - as if they are being attacked.

Ian Stallings
Tuesday, June 03, 2003

I thought computers flew modern airliners and that the pilots were there in case there's a problem and because people don't like the idea of there not being a pilot?

Anonymous
Tuesday, June 03, 2003

Surely pair programming involves the programmer on the left taking the left side of the keyboard and the programmer on the right taking the right? Not sure who gets the spacebar.

Anyway, you guys should really move up to the next level and enjoy the productivity gains offered by trio programming!

John Topley (www.johntopley.com)
Tuesday, June 03, 2003

[I thought computers flew modern airliners and that the pilots were there in case there's a problem and because people don't like the idea of there not being a pilot? ]

Yeah, what happens when the computer fails? Besides most airplanes are not equipped with complete computer control. Meaning most cannot go from takeoff to landing without intervention. In the future yes I think this will be the case but I think you might be missing the point.. Copilots and redundancy.

Ian Stallings
Tuesday, June 03, 2003

Modern computers never fail, we work in the industry, we know this to be true! ;-)

It reminds me of when the Docklands Light Railway was introduced in London. The trains were originally driver-less but people didn't like it so they now have an operative who (as far as I can tell) pretty much just sits there.

John Topley (www.johntopley.com)
Tuesday, June 03, 2003

*  Recent Topics

*  Fog Creek Home