PairingInAStrictHREnvironment

We have an issue here with pair programming and the company policy of individual responsibility for network usage. The "management information systems" and "human resources" departments have a very strong desire to be able to monitor and audit every user's individual network activity, for use as evidence in any disciplinary scenario that might occur in future.

They have noticed that our XP developers all log on to the development workstations (which are reserved exclusively for pairing on development tasks) using the same ID. They find this unacceptable. Their preferred solution is for the "driver" to be logged in, and then log out to allow the "navigator" to log in each time the keyboard changes hands. We find this unacceptable, for obvious reasons.

In search of a workable compromise, I'm wondering what other teams do as I can't imagine we are the only ones with this issue. So, stories please (and not speculation :) about your experience of this issue. Thanks. --KeithB

The HR argument is that if anything dodgy ever happened in future, and if it were traced to an ID of which more than one person knew the password then they would not know who to sack. YAGNI doesn't cut much ice with an administrator contemplating a wrongful dismissal tribunal. --KB

Keith, I'm unclear on what features a "workable" compromise would have for you. Have you explained your concerns to the administrators, and asked for their help in finding a solution that does not impair productivity, and hence your team, your department and ultimately the company's bottom line ? What was the reply ? -- LaurentB?

Good question. A Workable compromise is one that does not interrupt the flow of pairing with the need to log out/log in, or even switch to a different profile (as it seems that would lose context in the IDE, local servers etc.), or even go through some time-recording shennanigans to provide a minute-by-minute log of who was typing when (this has been suggested), as the keyboard changes hands between pairing developers.

The team discussed this and I have proposed to the business the team consensus, which is that the one pairing id (username "extreme") is available only on the designated pairing mahcines, and is the only login (bar "administrator" and such) that is available on those machines, and then we make it part of the "XP developer" role definition that we all take joint and several responsibility for what happens on those machines and with that login. This appeals to me since it is a sociological fix for a sociological problem, and is fully aligned with the values and principles of XP. I've yet to have a response.

My informal survey of other XP teams regarding this question has been illuminating. No-one is prepared to admit to having had this problem before (which amazes me). It seems that our situation is unusual in that 1) we have one "extreme" login under which all pairing occurs, rather than a pair's work being done under one member or the other's login, and 2) we have half as many pairing machines as developers, rather than a 1:1 pool of machines, half of which are idle during pairing time. I'm most reluctant to monkey around with either of these features of the environment, as they both seem to me to foster good practice. I should add that OliBye put this environment in place and did a pretty good job, I wouldn't want to do XP in any other scenario. So I'm particularly keen that HR don't break this scheme a few weeks before I export it to the new team in Singapore!--KB

I'm leaving this company --OliBye

Surely that's an over-reaction... :-)

Extreme? --OliBye

Maybe they could create the set of all possible permutations of pair-logins. Each permutation would have a unique password made of two halves. Each developer in the pair would be responsble for keeping his half of the password secret - so both partners need to be present to log in. To avoid being fired for something your partner did whilst you were on break, you'd have to lock the machine before turning your back on the monitor..... or the management could decide that this insanity has gone too far and trust the developers to get on with the work. -- AnonymousCoward?

I have great respect for the positive attitude of people trying to find a solution to this problem, however when I realised it was the company I'm leaving I had to laugh, words fail me, I can see where they're coming from and I'd happily to tell them where to go. --OliBye

Update Now that the "simple" solution (they tell us what to do, we do it) has not worked, and the ball is back in MIS/HR's court to assess our suggestion, the whole problem suddenly seems to have become much less important, and we have an instruction to carry on as usual until they get round to it...

Further Update Joint and several responsibility was not acceptable, there has to be a named individual. So, the suggestion now is that the coach of a team will take responsibility for what happens on the pairing machines only, uner the shared login only, and during pairing time only, whomever was using the machine at the time. As one of those coaches, I'm pretty happy with this, since I do actually trust my colleagues not to surf porn (well, not to surf porn on the pairing machines, uner the shared login, during pairing time :), and I'm not afraid to stand up and say so. --KB

Seems like a perfectly reasonable solution that accomodates everyone. I'm intrigured by the test built in to the solution. Unlesss the XP folks, in this case you, Keith, actually trusted your colleagues as you were asking the MIS and HR folks to do, the solution would fail. You'd back off. Real solutions to balancing agenda often have this kind of "money where your mouth is" element to them. In this case, the development team has to exhibit the trust they were asking of others. The MIS / HR folks have to exhibit some willingness to acknowledge that their concern is to have _some one person_ responsible for each act committed on one of the machines they administer.

I'll be curious how this plays out. As much as it is an inescapable reality, the process bound have a hard time coming to terms with the fact that in the end, you have to trust somebody, to some degree, or nothing gets done. Even in a secure environment working with classified material there are instances of "trust" and of delegated responsibility. Fascinating tale Keith. -- JB

Musing on this Story

Lots of folks are interested in free policies - free for them to implement. Anyone who's job includes managing risk but not results is at - er - risk of this. HR, for example, which is tasked with avoiding lawsuits and other legal claims but not with producing something. They will, absent some perspective, myopically make policies. They are ignorant, and managed to narrow goals vs. malicious. My personal favorite example of this involves computer security people who in the end are biased toward a computer locked in a darkened room connected to nothing. Such a computer is close to perfectly safe, but useless. Sometimes I have to point this fact out to them: All use of a computer to do some good includes associated risk to security.

Folks tasked with getting something done, even software folks, often engage in their own accidental (sometimes willful) unawareness of other folks' concerns. These range from regulation and lawsuits (which unfortunately every business in a Developed nation must consider at all times) to simple costs. I've seen dozens, no hundreds of developers who insist on their own desktop configuration without considering the possible effect on a LAN which someone else is tasked with keeping available. These same developers are the first to complain when their computing environment is down. They usually don't recognize that the beleagured LAN staff are solving a problem very different from "optimizing one developer's coding." The LAN support staff are usually managed as a cost, so their problem is keeping some minimum service up at all, for a big pile of people, at the least possible cost. They are chronically under-staffed. It's a crummy job most of the time.

The trick is to bring the concerns together. Rather than see the HR policy and it's abandonment as sinister or inconsistent, why not simply see it as everyone doing their job, perhaps with some ignorance? If it's free, HR & MIS have a perfectly legitimate concern to meet with the one-login policy. And why would they consider groups of people sharing a keyboard as dynamically as in pair programming? That's not what they are used to seeing. The development team also has a perfectly legitimate concern to assert about the policy, specifically: "This isn't free." So now someone has to make a tradeoff decision.

There's nothing necessarily sinister, or even myopic here. It's simply people who are new to each other working together in a business. HR and MIS folks, especially LAN administrators do tend to have an unfortunate communication style when it comes to policies. In part that's the mindset that fits people to such jobs. In part that's the crap that these people have to put up with. "New" folks to an organization will walk head-first into old assumptions in that organization. That's part of the price of being new, and of changing things.

The lesson that I'm inclined to take from this story has two parts. First, if I want to do something unusual, the support organizations may not be set up to accommodate that. Second, that I can give them the opportunity to be part of the solution. I can't count - literally can't count - the number or "uncooperative" and "reactive" LAN or Network support teams I've co-opted simply by starting out with: "I want to do something that I suspect is unusual around here. Let's figure out what it will take for you to support it . . . " If I'm flat out stiffed, which happens sometimes, I have a very interesting fact to kick upstairs to one of those trade-off decisions.

If in the end, my concerns and priorities are never considered, and there is no appeal, or no successful appeal, well, that's an important and useful piece of data.

But that's just me. -- JimBullock