17

I’ve been working in an eXtreme programming team and doing pair programming for over 7 years in a windows environment. When we first started doing it someone would log in with their windows credentials and therefore all access to domain resources, and more specifically version control, would be accountable to that windows user. Eventually we have evolved to have windows pairing accounts for specific pairing stations (e.g pairA, pairB, PairC etc…). All the devs know the passwords to these accounts. Accountability for commits (check-ins) is achieved by putting the programmers initials in the comment during the commit.

Up until now this has worked fine for us, but my company is currently going through a ISO 27001 audit and this was flagged up by the auditor as a risk. I have a number of possible solutions such as creating a pairing account for every pair combination, but I really would like to know whether anyone else has encountered this problem and how they solved it?

What solution was acceptable by the auditors?

Improve this question
5
  • 11
    I'd reckon that most people who employ pair programming practices think that all that ISO does is the date format and character encodings.
    – Lars Viklund
    Commented Jul 24, 2012 at 12:57
  • 6
    Why do you need to have pairing accounts? Wouldn't it work to keep individual accounts you can log into on any machine?
    – Garrett Hall
    Commented Jul 24, 2012 at 14:06
  • You can't use individual accounts because what happens if someone comes into the work early/goes to the toilet etc and the machine is logged in as the other user?
    – John Sibly
    Commented Jul 24, 2012 at 14:59
  • @JohnSibly Do you mean in the case of wanting to continue with work in progress on that account? Otherwise you should be able to open another session on the computer as your own user.
    – Sinjo
    Commented Jul 24, 2012 at 15:19
  • 2
    @JohnSibly, then the driver logs off, and lets the peer log on. If they go to the washroom, lock the machine if you don't trust your peers. However, no trust is a bigger issue that should be rectified.
    – CaffGeek
    Commented Jul 24, 2012 at 16:39

5 Answers 5

Reset to default
13

I would assume the auditors would prefer that developers log in as themselves and not as some "pair" which has a shared password. The risk should be obvious--a developer adds some malicious code as "PairA" and puts someone else's initials in the comment (or doesn't comment it at all). How do you trace back to the malicious developer?

I'd recommend that whoever is driving first (in a session) log in with his own ID, and the pair continue to put both of their initials in the comments--that way, the code remains traceable back to an actual developer.

Improve this answer
2
  • +1, this is what is done at my company. We have the choice of peer code review or pair programming. The pair programming case is just a special case of peer review, where the peer has been reviewing continuously while the code was written.
    – Daniel Pryden
    Commented Jul 24, 2012 at 18:13
  • @Daniel thanks for sharing your experience. When we first started pairing, it was the driver who would login. However our pairing sessions are now more promiscuous and quite often a pair will swap before a task is fully complete. Although this is not ideal it is sometimes necessary to orchestrate our swaps as everyone is required to pair on production code. This means the original 'driver' has to walk away and thus log out. We can get that code checked in without them, but the disruption to the pair, who are potentially in the middle of debugging the app, is not too be taken lightly.
    – Martin Hughes
    Commented Jul 26, 2012 at 14:56
8

I would keep the accounts as they are, typically only one person is driving, and even if the other person uses the machine (unofficially) the person logged in should still be aware of what is happening on their machine.

Checkins would still need comments to show who the pair was however.

Improve this answer
2
  • Do you mean keep the pair accounts ("keep the accounts as they are"), or use individual accounts ("the person logged in")?
    – Caleb
    Commented Jul 24, 2012 at 16:42
  • @Caleb, individual as the person logged in who is doing the driving
    – CaffGeek
    Commented Jul 24, 2012 at 16:56
6

Instead of creating separate accounts so that work is not locked to a possibly absent user, use your version control system. When a pair starts working, create a task branch. Commit code to the task branch whenever the tests pass. When the task is complete, merge back and close the task branch.

Improve this answer
5

Up until now this has worked fine for us, but my company is currently going through a ISO 27001 audit

ISO 27001 or not, your current system only works because you're a small company where there's a high degree of communication and mutual trust. That sort of thing doesn't scale up very well, so you'd probably have to consider other options at some point in the future anyway.

Creating a separate account for every possible pair seems even less practical: you'd need 90 accounts for a group of 10 developers, and each of those 10 developers would have to know 9 different login/password combinations.

The only practical solution is to use individual accounts, as others have suggested, and track the identity of the second person in the pair some other way (comment in your version control commit, field in the issue tracking system, etc.).

Improve this answer
2

For Pete's sake, let the driving member of the pair take credit/responsability for the push/commit. Next time the other member will drive. The "driver" will not do anything he doesn't agree upon whith the co-pilot.

Programming is a colaborative effort. No programming deed is 100% individual. There's no need to be fastidious wanting to reflect that a given push/commit was done by Tom and Harry and not just Tom. The benefits of pair programming are worth overlooking that nuance.

The auditor is right, "pool" accounts should be avoided.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.