Why I like Pair Programming
Pair programming is easily the most controversial agile development practice and in my experience the most frequently avoided. It makes some people pretty uncomfortable.
Pair programming means two developers working together on one computer. It promotes working very closely with your fellow developers and forces you to learn from your colleagues. It helps to decrease or eliminate key person dependency and promotes unified naming conventions and code structures. So why don’t we like it?
Why the negativity?
Let’s face facts – most software developers shun the idea of pair programming. The basic concept of working with someone looking over your shoulder or (even worse) having to look over someone else’s shoulder while they’re working doesn’t really sound appealing. You also have to deal with one of your colleagues invading your personal space – not a very pleasant thought.
I guess at the end of the day we all want to be rock-star developers: music on, eyes glued to the monitor, fingers moving across the keyboard at lightning speed… Unfortunately this is not the picture of a productive developer. Programming is not about creating software as fast as possible – it’s about creating bug-free, testable, consistent, maintainable software that will outlast us all while being flexible enough to meet changing business needs. The rock-star developer simply doesn’t fit into this mould.
The problem is that the rock-star doesn’t communicate with his fellow developers. He doesn’t follow coding standards. He doesn’t write automated tests. He doesn’t care about your naming conventions and he sure as hell doesn’t care about re-using your code. Pair programming prevents you from being a rock-star developer – and that’s a good thing.
Resist the rock-star developer!
Once you get used to the idea of constantly engaging with a fellow developer it can actually be pretty fun. You’ll be learning new concepts and patterns. You’ll be bouncing ideas around all the time. If you need to talk through a problematic piece of code – there is someone sitting right next to you!
I especially like pair programming because it forces me to be productive while at my desk. Let’s face it – we’re al human. After banging away at the keyboard for a few hours you are going to lose concentration – check you email, read the news, chat on msn – you need to do something to let your fingers and mind rest. When I’m pair programming I find this isn’t really an issue – if you find yourself getting tired simply stop typing and hand the keyboard to your pair. I find this switch allows me to stay productive for pretty much the whole day.
It’s still a difficult sell
It’s still difficult to convince your fellow developers and managers that pair programming is the way to go. Initially you won’t be as productive as before – pair programming, as everything in software development, takes some experience to really get the most out of it. Plus you will need to convince your management that it will now take 2 developers to do the work that one usually did.
But don’t be discouraged. The long-term benefits of pair programming are incredible. Your team will produce consistent code with less bugs in a shorter space of time while increasing the technical skills of all the developers. You will probably get a lot of resistance (from developers and management alike). Don’t despair – keep at it – once they see the benefits, developers and management alike will come to the party.
The benefits of pair programming are simply too great for us not to be doing it. Happy coding.