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?
5
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.
2
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.
2
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.
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.).
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.