I began working in the wonderful world of technology in the early 1980’s. Long ago enough to remember when, if you were lucky, computing didn’t mean punch cards and batch jobs, but a mainframe computer that you worked on in real-time via a dumb terminal. We called it time-sharing. Today, I guess it would be called The Cloud (a technology term that has as elastic a definition as any bit o’ technology I’ve come across in 30+ years.)
Anyway, when I first began working in tech, I worked for a small company that offered time-sharing services to Fortune 500’s . Our service was slices of time and computing power during which our customers could access data, run reports, write programs, create models. We also offered consulting services, in which we were the ones who’d access data, run reports, write programs, create models for our clients. We also had our very own computer language, XSIM, which was what we and our clients used to access data, run reports, write programs, create models.
We did our work in a communal area called “the terminal room” that had a dozen or so mostly paper-based terminals, and a few coveted screen terminals, that were connected to our mainframe.
Those of us who needed to use the terminals to get our work done outnumbered those terminals by a factor of about 3:1.
We operated under a set of informal rules. You could stay at a terminal for as long as you needed to, but you really weren’t supposed to be a hog and monopolize it for the whole day unless you were working on deadline. Whether on deadline or not, if you left for more than 20 minutes, someone could grab your terminal and put it to sleep, preserving someone’s work wherever they’d left it, but free to open up and get moving on a task of your own. Occasionally there were minor spats, but it generally worked pretty well.
And although it could be annoying at times, working in the terminal room was actually fun. There was always someone to get help from if you were stuck on a problem, which happened to me often enough. XSIM was more “user-friendly” that coding in binary, but it wasn’t all that intuitive.
When screen-based terminals – VT 131’s – in our offices replaced paper-based terminals – DecWriters – in the terminal room, the culture of the workplace changed.
Anyway, although the situations aren’t totally analogous, the terminal room was what jumped into my mind when I saw an article in the WSJ on something called “paired programming”. Paired programming is:
…where two people share one desk and one computer. One person is the "driver," controlling the keyboard and typing in code. The other "navigates," monitoring design and scanning for bugs.
It’s collaboration taken to the extreme, and it’s in use in Silicon Valley in companies from wacky start-ups to Facebook.
Its advocates speak in glowing terms of the power of coupling, saying paired coders can catch costly software errors and are less likely to waste time surfing the Web.
Interesting, that “waste time surfing” note. The most solid programmer I ever worked in – fast, meticulous, pitch-perfect – spent half her day knitting while watching soap operas on a small b&w TV in her office. (This was the pre-Internet days, so no Web surfing.) It was during that knitting to All My Children time that she worked out what she was going to write. She then went ahead and did her coding, with all the problems solved ahead of time.
"The communication becomes so deep that you don't even use words anymore," says Kent Beck, a programmer at Facebook and a strong advocate of pairing. "You just grunt and point."
While I’m not all that keen on grunting and pointing, I’m all for collaboration. Two heads better than one, etc. But I’m also all in favor of just getting my own work done, and having it be mine. (Not to mention being able to do it at a desk of my own. Sharing an office is one thing. A desk and a computer: a bit too Siamese-twin-ny for me.)
Two recent projects of mine, both white papers, come to mind.
In Project A, I was given the topic, did some research, and came up with some questions for company experts. We spent an hour together in a virtual meeting, going though my questions, exploring themes, gathering input. I then went off and wrote the white paper. After a couple of review rounds, we were done. A nice collaborative project – and mine. Even though my name wasn’t on it.
In Project B, the white paper was written by committee. I was provided with some ideas and raw input, made a first pass – sort of – and from that point on worked more or less as a copy editor for multiple on multiple on multiple iterations. I don’t think there are many spots where there are more than a couple of sentences in a row that were actually written by me. Oddly, they credited me as an author, when the credit should, at best, have been as the midwife. Nowhere near as satisfying as Project A. But because I really like the client, I would do a similar project for them again. Even though I derived far less satisfaction, pride, and sense of ownership from the Project B effort than I did from Project A.
So I’m with the programmers who aren’t completely grocking to paired programming.
If the ideal for pairing is soulmate-level bonding, the reality can be more like an endless bad blind date. Annoyances that plague partners everywhere can quickly pile up: from poor personal hygiene and table manners, to feet on shared desks and loud chewing.
But the theory is that programming by duet would result in faster, cheaper, better software production.
Maybe, maybe not.
The story about how it came about pairs Facebook’s Kent Beck with Ward Cunningham (developer of the first wiki) – who worked together back in the 1980’s at a software company.
The relationship began when Mr. Cunningham asked Mr. Beck to check for bugs in a software application he was working on. But eventually the collaboration grew deeper, and the two would pair up to knock out assignments so they could move on to their own pet projects.
The checking for bugs I totally get. Even the deeper collaboration.
But I just don’t see that it would work well for everybody. Which of course it doesn’t.
But there are plenty who do it, and there are a number of variants, including part time vs. full time coupling. Then there are “promiscuous” pairers who switch partners every day.
Ping-pong pairing involves hopping back and forth between partners. Remote pairing is the computer world's version of the long-distance relationship, with programmers sharing the same screen via the Internet.
Since I’m always juggling multiple projects/multiple clients, I guess I’m doing ping-pong pairing, of sorts. And sometimes I do white-boarding, so there’s a remote pairing angle to my work, too.
But I’d never be able to get into it for core writing projects. One thing to edit and rewrite this way, one thing to kick around ideas ahead of time, but when I sit down in front of the blank page, I absolutely DO NOT want to see someone else’s fingers start doing the walking.
No comments:
Post a Comment