Lets say you’ve read the various justifications for pair programming and you have decided to give it a trial or perhaps you’ve already tried it and not been successful. What things can you do to give pairing the best chance of success and make it a pleasant experience for all?
Lots has been said about the day to day practice of pairing but here I want to look at some of the more practical physical office considerations that can, in my view make or break a team.
Sort the furniture out
A poorly laid out office can destroy your chances of a successful pairing experience before you have even begun. If your desks are arranged like those on the left above you are not going to have a fun time. Not only this you could even be breaking regulations on providing a safe working environment for office workers. The pairing station on the right shows the set up at transFICC.com
Get rid of those L shaped desks and dividers if you have them Straight desks with no obstructions underneath provide a much more comfortable place to sit. Aligning PC ‘s lengthways at the back of the desk can free up leg room and don’t have under-desk pedestals – put them at the end of desk rows if you must have them.
This is the single most important piece of advice in this article if you do nothing else – do this.
Provide breakout areas
“lots of drawing on walls” Gavin Tapp CC BY 2.0 via http://www.flickr.com
Its not all typing. Its really important not to spend all the time coding at the workstation, we often need to go and sketch out ideas and discuss them away from the screens. Pairs should be encouraged to and given somewhere to breakout and have design discussions. Seating areas with tables and whiteboards everywhere should be the norm for any agile team. Painting the walls with whiteboard paint is really effective.
Provide standardised machine configuration
“My laptop stickers came” Doug Belshaw CC BY 2.0 via fickr.com
How someone has their machine set up can be a very personal thing, keyboard short-cuts, themes etc. This can make it very difficult to enable a sense of shared ownership and collaboration. So don’t just pair by bringing along one of the developers laptop’s. Get pairing stations set up with two keyboards, two mice and two screens. Configure these in a standard way ideally with automation such as puppet or chef. This enables you to clean install the station every night and will ensure that any developer can work on any workstation and will immediately be in a familiar environment. It also encourages the frequent small check-ins approach used in XP & Continuous Delivery. You should be checking in your IDE configuration with your source code to ensure “Everything is in Source Control”.
I recommend the team agrees on a single IDE (or text editor if you must, if you are still having vim/emacs wars maybe this is an opportunity to move on a decade) for pairing.
Tip have a USB hub on the desk with spare slots – this allows people to plug in personal mice/keyboards if they have particular styles they like or want to for hygiene reasons, it also provides somewhere to charge your phone 🙂
This is an opportunity by the way to get a much higher specification machine for development – you need only enough machines for one between two.
Hot desking
“Pairing Station” by Andrew CC BY SA 2.0 via http://www.flickr.com
Pairing with the same person for day after day not only gets monotonous it also misses out on the knowledge sharing and team building that pairing brings. You need to be rotating pairs at least daily, for this reason I don’t recommend trial pairing with just a single pair you are unlikely to see any real benefits. If you are doing this, hot desking is really a pre-requisite as people are, by definition, moving around every day. But you can think about a couple of things to make this run better.
Make sure every desk is equipped with a fully set up pairing workstation as mentioned above with dual keyboards and screens.
Have a bank of desks dedicated to each team but encourage full hot desking within that area.
Many people want to keep using the same chair so just get some labels and stick them on its a small price to pay for comfort.
Don’t forget to have white boards and the team board near by.
Clean desk policy
CC 0 Public Domain via Pixabay.com
Clean desk policy can be controversial but it ensures that desks are truly hot.
Have someone responsible every evening (Cleaner or office admin perhaps) for clearing all the papers and books into a document tray
Also have them replenish every desk with a supply of post-it notes, sharpies, pens, note paper and whiteboard markers. When we started doing this almost no-one complained any more about the clean desk policy, it seems people value having tools to hand over an untidy desk.
Final thoughts
Although this article is written with pairing in mind, even if you are not pairing regularly many of these tips still apply and will in themselves encourage greater team collaboration. In particular sorting out the furniture, providing breakout areas standard machine setups with dual keyboards and screens will allow ad hoc pairing to occur on an informal basis. The “Could you just help me with this a minute” situation.
So before you embark on your pairing trial I would strongly recommend these measures, I consider the furniture and standardised workstations pretty much essential.
- Sort the furniture out
- Provide Breakout areas
- Provide standardised machine configuration
- Hot desk
- Clean desk
Further reading
Pair Programming – The most Extreme XP Practice? – Dave Farley
Why pair programming is as much about business continuity as it is about code quality – Dave Hounslow
Good stuff!
One comment on “You should be checking in your IDE configuration with your source code”. An acceptable (or possibly better) alternative is to generate/import the IDE configuration from the build meta data. With the build configuration committed to source control (obviously).
If your build system doesn’t support this, look for a new one (I’m looking at you ‘Ant’).
LikeLike
Good point Mike. I’ve been working with NodeJs for a while and I’d forgotten how much tool integration had moved on for languages like Java.
LikeLike
Out of all “methodologies” and “best practices” pair programming is the worst that ever been invented for Software development as a profession. If widely accepted it will seriously undermine the profession of software development.
LikeLike
I’d be interested to see your evidence for this. Research exists to the contrary (https://collaboration.csc.ncsu.edu/laurie/Papers/ieeeSoftware.PDF)
Pair programming is often frowned upon by those people and organisations that have not tried it. I have met very few developers who are productive members of a team individually who having tried it do not find pairing to both be a more productive and enjoyable way to work. (Dave Farley discusses this here; http://www.theregister.co.uk/2016/04/12/pair_programming_the_most_extreme_xp_practice/)
And of course there is the business case for pair programming as I talk about in my article https://thinkfoo.wordpress.com/2014/05/25/why-pair-programing-is-as-much-about-business-continuity-as-it-is-about-code-quality/
LikeLike
I am well familiar with the research done in University of Utah. I am also well aware that this is practically the only research that is behind the claims of Pair Programming advocates.
If one read carefully what the actual experiment was, one would easily see that it had nothing to do with real life.
The experiment in University of Utah involved short artificial coding tasks performed by student with very little programming experience. It is not what real development is about.
Unfortunately this paper does not describe what the assignment was, what programming language and development tools were used. It also never mentions the types of errors that students made (one would expect this if all is based on a claim that number of error was lower in case of pair programming). Which gives a suspicion that the test was specifically designed to give an advantage to those working in pairs.
LikeLike
[…] you’re looking for more ideas and pictures on how to fix your pairing setup, have a look at ThinkFoo and Agile in a Flash. I found both resources to be invaluable when writing this […]
LikeLike