Kathy Sierra's Blog

March 2004 Archives

Pair Programming is NOT always a choice

I know this subject has been talked about practically to death, but from what I have read, there's an assumption about Pair Programming that I believe... no, I know is Just Plain Wrong.

The assumption is this: Paired Programming is a Choice.

I don't like the idea of Paired Programming.

That's because you haven't tried it. You're just afraid to try something new.

No, I really DID try it.

You obviously didn't try it RIGHT. I'm sure you missed some key point about how to do it.

No, I was in an XP shop that had been doing it for a long time, with a lot of success.

Oh, so it's YOU that's the problem. Yeah, XP really smokes out who is and is not capable of being a good Team Player. Must be an ego thing.

No, I've always considered myself a really good team player and collaborator. I get high marks for this on every performance review I've had... from every manager I've had, and I've never had any trouble working well with co-workers.

Like I said, sometimes it takes XP to smoke out who is REALLY a Team Player. There's no room today for loners.

I know the arguments for and against XP, and I'm personally in favor of most of XP. I know the case for Paired Programming. I know the benefits. I know the studies and real results. I also know that for most people, Paired Programming really is a choice. That's because most people fall into the category known as Non-Loners. The masses. The majority.

But there is a minority (and they can't just be defined by a simple Meyers-Briggs type) for whom the idea of Paired Programming is NOT a choice any more than is their sexual orientation. People for whom the idea of being Not Alone that much (and with someone with whom they do not already have an intimate relationship) makes them as crazy as being alone makes Non-Loners, well, lonely.

One problem is that the majority world of Non-Loners largely views Loners as maladjusted. A condition to be "fixed". The "L" word has been perpetuated, especially by the media, to represent something sad, or worse, scary. On any given day, somewhere in the world (especially the US) a reporter is saying, "Neighbors describe the [mass murderer, pyromaniac, etc] as a loner." In reality, most of these so-called evil loners were in fact Non-Loners who were rejected by others and didn't take it well.

I simply NEED to work alone (which doesn't have to mean in my own office or anything... I can be alone sitting three feet from someone else) for larger portions of the day than the traditional Pair Programming model allows. For me, this is a need, not a choice. And please don't suggest that I have no self-awareness... most True Loners have fought the masses and the negative stereotypes long enough to know the difference between a need and a choice. We're the ones who who have to risk the life of another person (as in, "You'll kill your Aunt Betty if you don't come to the family reunion...") to protect our own sanity.

Non-loners experience real, physical symptoms of lonliness when forced to spend too much time NOT in the company of others. They become stressed, depressed, anxious. Loners, on the other hand, experience physical symptoms when they they don't have enough alone time. For us, time-without-company (espcially company not of our own choosing) is as necessary as water and oxygen. Not a habit. Not something to be learned. Not a choice.

However, the True Loner is definitely in the minority. So I believe an XP manager should spend time and energy to smoke out which of the reluctant programmers really ARE merely afraid vs. True Loners. In most cases, it's the former, and a gentle introduction is probably all that's needed. But ignoring that True Loners like me exist won't make us go away. And you're more likely to find the True Loner in the programming profession than, say, marketing.

We exist. The question is, what will you DO with us? Do you force us until we either numb ourselves to the overwhelming togetherness or just leave because we can't stand it? Do you find other tasks for us that aren't on the project? Do you fire us for non-compliance? Or do you find a way to exploit our strengths?

I'm not sure what the answer is. As a manager (and I was always a really bad one), I'd probably be tempted to say sacrifice the one for the many. But does that really, in the long run, serve the company and the team best? Is there really no other way to get the benefits of XP Pair Programming than by this particular (sit side-by-side, etc.) implementation? Because True Loners aren't against team work and being with people. Heck, I sit five feet away from my co-author/partner all day long, every day. It works GREAT for us. This does NOT violate my sense of aloneness, and we collaborate throughout the day, brainstorm, review each other's work, etc. A True Loner doesn't need or necessarily want to be in Solitary Confinement. And again, please don't confuse being a Loner with not being a team player. These are two completely different things. The majority of people are Non-Loners, and you'll find plenty of non-team-players among those ranks.

Part of the reason I felt compelled to post this is because True Loners by definition don't "stand together". There's no group advocating for the Loner. We don't get together with others of our own kind. We don't form clubs. We don't have meetings. But my heart nearly breaks for the True Loner not just forced but often humiliated into participating in Paired Programming, lest he or she be viewed as Not A Good Person. Which means, Not Like Most People. For most Non-Loners (except those that have come to know and appreciate a Loner), the True Loner simply does not represent Goodness. Non-Loner == Good and Normal. Loner == Trouble.

If you are (or suspect you might be) a True Loner, you might consider the book Party of One: The Loner's Manifesto. If you're a manager, and you suspect that you might have a True Loner in your midst, or you're perhaps in a relationship with someone you think might be a True Loner, you can read the book to learn more about us. To see that we're not evil, stuck-up, cold. We're just different. If you're a Non-Loner with negative feelings about True Loners, perhaps it's because you're afraid of something new? ; )

And maybe you wouldn't have wanted any of these folks on any team of yours, but the world is filled with examples of True Loners who made a difference in the world. As "Party of One" author Anneli Rufus puts it in the book, "Down the years, around the world, they form a shining line -- in single file, of course. Da Vinci. Michelangelo. Issac Newton. Rene Descartes. Issac Newton. Kipling. Thoreau. Beatrix Potter. Dickinson. Lawrence of Arabia." She later includes Alec Guinness and Albert Einstein. Do we have anything to offer the project, even if we can't survive Paired Programming? Maybe not. But this passage from Rufus makes me feel better about it:

"Yet here we are, not sad, not lonely, having the time of our lives amid their smear campaign. We are the ones who know how to entertain ourselves. How to learn without taking a class. How to contemplate and how to create. Loners, by virtue of being loners, of celebrating the state of standing alone, have an innate advantage when it comes to being brave;; like pioneers, like mountain men, iconoclasts, rebels and sole survivors. Loners have an advantage when faced with the unknown, the never-done-before and the unprecedented. An advantage when it comes to being mindful like the Buddhists, spontaneous like the Taoists, crucibles of concentrated prayer like the desert saints, esoteric like the Kabbalists. Loners, by virtue of being loners, have at their fingertips the undiscovered, the unique, the rarefied. Innate advantages when it comes to imagination, concentration, inner discipline. A knack for invention, originality, for finding resources in what others would call vacuums. A knack for visions."

At least that's what we True Loners like to believe when we're labeled at best "not a team player" and at worst, "an axe-murderer". Besides, we're cheaper in the long run. We rarely stay for the pizza and beer parties. ; )

How are you on a blind date?

Maybe your mother knows more about software development than you ever imagined. Perhaps the advice she gave you before that fateful blind date--with that special someone your friends convinced you was The One For You--works for software development as well as dating. The assumption here is that you are crafting something that someone else will be using, and it works the same whether you're designing an API for other developers, or an end-user experience rendered through your Swing GUI or browser-based web app.

Wear Your Good Shirt

Face it--how you look does matter. In fact it matters more now than it did before, as we've evolved (for better or worse) into a Culture of Style. The bar has been raised; your target market (not that you should refer to your prospective date that way, but still...) expects more than just functional today. Look at the iPod phenomenon. Dozens of devices play mp3's, and for less money, but people keep choosing sleek and sexy (or today, colorful) over purely functional. In other words, you can't just get the job done--you need to look good doing it.

Now, before you flame me about how surely Ease of Use (and ReUse) is more important than Look and Feel, keep in mind that the two aren't entirely orthogonal. The most successful designers, engineers, and architects in the world understand that beauty lures the user into the experience in a more intimate, engaged way. Quite possibly my favorite geek book in the world is Gelernter's "Machine Beauty" where he explains "how beauty drives the computer revolution: how lust for beauty and elegance underpinned the most important discoveries in computational history and continues to push research onward today."

And come on--can you honestly say that you have never looked at some code, an algorithm, an API, an implementation, or a UI and used a word like "elegant", "sleek", "slick", "cool", "beautiful", or "sexy"? We're human beings, and we're genetically programmed to respond to beauty. Give someone an ugly-yet-functional application or API and they might find it perfectly acceptable, but they won't have that transcendent experience.

In a previous blog about API design, I suggested Don Norman's book The Design of Everyday Things.. And in that book he claims that there's no excuse for making something hard to use. But some of his proposed solutions are a little, well, unattractive. In fact, he rails on engineers and designers for making something look slick (like by using fewer buttons and instead making the existing controls modal) at the expense of usability. And I agree. But why should it have to be an either/or choice? Usability/functionality vs. elegance/beauty? And even Don Norman admits now that it's time for products that will "appeal to the emotions as well as to reason". His new book Emotional Design is driven by his goal to make products more alluring. He says, "For years I worked hard to ensure that products were usable. Now it is time to make sure they are pleasurable as well. Usable, effective products need not be ugly or dull. So, I'm on a campaign to ensure that our products have beauty and emotional impact as well as effectiveness and understandability."

But wearing your good shirt isn't just about looking good--it's about showing respect for the other person. How would (or if you've got some experience with this, how DID) you feel if your blind date couldn't be bothered to even find something clean? Besides, first impressions tend to be metaphorical... I just got off an airplane a little while ago coming back from the Software Development conference. The airplane seat back tray table was a little dirty, and that always makes me wonder, "What else didn't they maintain on this plane?" (a comment which made fellow java.net blogger Sue Spielman say, "Remind me never to sit next to YOU on a plane"). If your code, API, interface gives users a first impression that you didn't take the extra care to make something look decent, that sets the tone for how they view everything they see of yours after that. And it takes a lot more work to undo a first impression.

OK, so does this assume that every product, bit of code, interface, or API has to conform to some extremely high, fully-accepted standard of beauty? To bring this back to dating, does that mean every male must look like he stepped out of the pages of GQ, and every female the pages of Vogue? Of course not! No, I said, "Wear your good shirt", not "Look like a model." In other words, pay attention to aesthetics. Put it on your priority list. It's about acknowledging that the end-user has an aesthetic sensibility, and putting some effort into making what you've got appealing.

Don't Assume You'll Never Have Competition

You can get away with ignoring the "Wear Your Good Shirt" rule while you have no competition. If you're the only member of whatever sex the datee is looking for, it might be less a factor. If you're the only API, product, framework, game in town, for example, you can probably survive and even thrive being sloppy and unattractive. But what happens when you're no longer the only player in the field?

Don't Be Fake

Don't act like you're one thing and suddenly become another. Be honest. Be real. Be yourself. We've all seen software that starts out nice and friendly, and then switches into something different. A long time ago, there was a comparison made between the Macintosh OS and Windows, that went something like this (can't remember the exact original), "With Windows and the Mac OS, it's like you're in a lovely lobby of a nice hotel. But with Windows, you can make one wrong turn and suddenly find yourself thrown into the boiler room." Being clean and honest is better than being a poser. Brenda Laurel, in her book, Computers as Theatre believes a software system should always "stay in character", and that the end-user should be able to rely on what the system initially appears to be.

Be Fun. Be Someone Others Want To Be With. Don't Be Negative.

I wrote my first book using the publisher's Microsoft Word template. I was depressed for about six months. I sat five feet away from my co-author, also working in Word, and I had to listen to him swear several times a day. When we started our next book, we switched to InDesign. And the world brightened. The weather was always a little sunnier. More flowers bloomed in the yard. The pets and kids were better behaved. Of course, this assumes that InDesign was suited for our particular task, and it was, beautifully. But wow--it was like falling in love.

Make a list, even a short one, of the products, APIs, frameworks that made you happy. That made you think, "This is awesome. This is perfect." Now make a list of the ones you struggled with (I'm wildly speculating that this second list will be, um, longer). Next time you design and build something, try to focus on having that thing end up on someone's "made me happy" list. You'll have their undying loyalty and respect for life.

It's Not About You.

Who would you prefer to be with: someone who you are impressed with, or someone who makes you impressed with yourself? Someone who makes you think, "Wow, that person is so much better than I am." or someone who makes you feel, "I rock!"

You know when you're around someone special when they bring out the best in YOU, as opposed to leaving you in awe of who THEY are. When you feel good about yourself, and your capabilities. On the other hand, the people you're less likely to date are those that leave you feeling somehow less capable. Less smart. Less attractive. Less clever, less interesting, less... you get the idea. Way, way too many APIs, books, products, interface, programs, seem designed to get the user to recognize how smart the designer was, when the most appealing products should leave the user recognizing how smart the USER is. If the API you design leaves the programmer feeling frustrated and stupid, they'll run like hell the next time they're given a choice between something that you've designed and something from another candidate. And we all know that lowering someone's self-esteem is NEVER a good recipe for bringing out someone's finest work.

So don't focus on what YOU do... focus your energy on that other person. Paste a picture of him or her (and if you're building for a large unknown group, just pick a picture of someone who represents a member of that target group) on your monitor. Always remember that your work is about THEM, not YOU. Instead of thinking, "What cool thing can I do?" think, "What cool thing will my work let him do?"

Be Polite.

Your mother warned you about good manners. Imagine you're on a first date and suddenly the person you're dating just gets up and walks away, without a word. No indication of where they're going or when they'll return. Ever had a software app do that to you? The little things like progress meters REALLY matter. If you don't think it's good to be rude, then don't have your software apps be rude either. Let people know what's happening. Reassure them. Reduce their stress.

But I think there's a fairly simple solution, and it gets back to the first blog I made here--make the receivers of your product or service humans. Not abstract "users" that appear on a report somewhere. Not abstract "customers" or "programmers", but REAL living breathing people. Find ways to force yourself to see those who receive your work as individuals with needs, concerns, issues of their own. You KNOW how it feels when you do something that delights someone, right? Like, when you cook something for someone (which in my case, is limited to grilled cheese and pancakes, but still... I'm brilliant at them), and you watch their face intently as they chew the first bite. You're looking for that little smile... that subtle way their face lights up and you know you've made them happy. Think about the ways in which someone else's pleasure makes you feel good. If you can truly conjure that sensibility when you're designing a product or API, you'll have to hire a bodyguard to fight off the rabid fans.

I'm serious about the picture thing. I pasted pictures of customers in my cube. I made a sign when I was at Sun that said, "Someone just paid $3,000 for my service. Was I worth it?" and eventually I started seeing those same signs tacked up throughout our building. (With some minor word changes, although I can't understand why... ; ) And if you're a manager, encourage your staff to watch video tapes of REAL people or better yet, TALK to real customers. Last time I blogged about this someone commented that if management is doing their job correctly, workers shouldn't have to have any contact with customers. In other words, the spec should say it all. But what I'm talking about goes beyond the cold, hard, specification and into the realm of emotions and beauty and passion.

I have to believe that if I had a webcam at home, and the developers of Adobe InDesign could watch me at work, it would make them happy to hear me say, "I LOVE this program!" at least once a day (and this is after more than a year of full-time use). That doesn't mean that I don't have some issues and complaints, but as it is with any worthwhile relationship, when you're head over heels in love, you don't dump them just because they don't meet every possible need.

Perhaps instead of reading so many technical books, developers should go back and ask their mothers for some good old fashioned dating advice. And hey, just because you're already in a long-term, committed relationship doesn't mean you should take ANYTHING for granted. Imagine how delighted your long-term partner would be if you came home one day acting much the way you did back in the days when you were still trying to impress them ; ) Just because you've got customers you don't believe can, or will, go anywhere else shouldn't be an excuse for slipping on the fundamentals. Putting a smile on someone's face can be so easy... you can usually delight someone simply by doing just a tiny bit more than they expected. Imagine a world where we all work just .01% harder at trying to put a smile on someone else's face : )

This work is licensed under a Creative Commons License.