Pair Programming With Marketing Types

Sounds dangerous. Wouldn't that suck the clues right out of your head?

What if you want to practice ExtremeProgramming but you are the only developer in your organization. Can some of the benefits of PairProgramming be realized by partnering with people who have little or no knowledge of coding?

Since I'm the only developer in the company, I decided to try this with our Director of Marketing (he fulfills the role of Customer) and it's been 'very' interesting.

(Obviously, I'm a little bent to even consider such a ludicrous idea... same goes for the marketing guy. I have a bit of a split personality; when I'm writing code, I'm thinking about what's going on on all these different levels inside the machine, but when I use someone else's software, I switch into DumbUserMode --and that's exactly the way I like it. I like clean and subtle interfaces that require very little conscious thought on my part -- in fact, in the rare cases where I have the choice, I prefer real knobs and levers over their screen equivalents. ReinventTheInputDevice? anyone?)

In any case, because of my "sickness", I might be better equipped to bridge a gap with "the enemy" ;) It doesn't hurt that my coworker spent some time in the trenches taking customer support calls for a large computer company. He's not running a huge surplus of clues, but it is a surplus, and my clue reserve is thankfully spared... ;)

Clearly, I do all the typing, and that at about half-speed since I'm describing what I'm doing at a level of detail that would be unnecessary for a programmer. Our "Customer" is now able to understand what I'm doing with little explanation on my part, he can read control constructs, understands the basic concepts of objects and classes, and always remembers to make sure I run the UnitTest suite.

Arriving at this point wasn't painless, and I doubt there are too many out there who would want to spend their time trying to train a marketer, nor would I blame them. For those who are curious; it takes patience, for sure, but here are some of the benefits we saw (your mileage may vary ;)

I'm still learning my way around the problem domain - this guy lives in it. A lot of uncertainties come up while coding. Often the decision of how to handle these unknowns rightly belongs with the customer. If the customer is right there, I can ask him. If the customer's not readily available, I might be tempted to make an ExecutiveDecision? about what seem at the time to be "mundane details".
In a sense, I'm absolved of responsibility for the business logic - I write out a flowchart, we review it, I write some pseudocode following the flow chart, and he can see that logic in the code, right there on my screen.
He now has a better understanding of what is required to handle software design (of course I'm still doing the heavy lifting, and if he gets out of line I just stand up and point to the keyboard ;)
He has a much better understanding of the actual workings of our product and is therefore in a better position to support our customers when they have problems

I don't think that this practice would go over well if imposed from on high, and for all I know it may not even be repeatable. Food for thought though... I doubt I'm the first person to try something like this, and would like to hear about other's experiences-- good and bad.

-BenSharp

BenSharp used to practice PairProgrammingWithMarketingTypes, could these experiences be shared? How to pair program with somebody who knows little or no programming?

There's no XP methodology etc in my company. But I do this with business people whenever there's opportunity. This way, they can visualize how difficult programming effort is. And from then, they're more realistic about requirements and forgiving about bugs, deadlines etc.

In fairness, I hope that you also accompany them from time to time on sales calls, meetings with the promotion agency, and presentations for the executive board. It helps you be more realistic and forgiving about ad buy lead times, sales closing techniques, managing board members, and so on.

CategoryPairProgramming