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.
Posts
8 comments:
Nice post.
One more thing to mention. If you are leading the pair, you can also benefit from pair programming, improving your teaching skills and ability of the team for self-management.
Thanks Vasil. I agree - there are so many benefits to pair programming and quite a few are not related to technical skill. It's a real pity that it's not simply standard practice...
Don't forget the doubled employee costs. Tho you might avoid things you would have to do anyway afterwards when doing classic programming, you basically still work at the speed of one programmer - paying two for it. That's not very appealing for many companies.
Despite it's drawbacks, classic programming (or less expensive ways than pair programming) is much faster. And you can do good code too if you're working disciplined in a classic team and have a good team leader. Tho, the learning curve is much steeper with pair programming.
BTW: cursor and other keys don't work in this textbox with FF 3.0.x ;)
Hey Jaco,
Just a suggestion, maybe have a archive list and tag cloud on the blog. would be really usefull
Nice post. Tag cloud definitely need to add. Thanks
@Roman - I don't really agree with your argument that pair programming doubles the cost of development. I've read that studies about pair programming have shown that 2 developers working together can be more than double as productive as 1 developer working alone. A good team lead and discipline definitely helps - but that's true whether you're working in pairs or not. Remember the 'speed' of development is something of a myth - if one team does the code in 50% of the time that doesn't really help if there are 50% more bugs. Meeting some initial release date is futile if the code cannot be maintained and more has to be spent to fix bugs.
But again, this is my opinion.
@anon and @night-fairy-tales - I've added the archive, trying to figure out how to add a tag cloud in blogger. Thanks for the advice.
I for one prefer code reviews done in a structured way. Unfortunately developers are human beings and some may get use to it and others will hate it. Hating something will make you less productive.
It all depends on your team, if they are like minded it will work, if not, then the traditional setup of a few developers paired with an architect that does code reviews in a structured way might work better.
I am on the developers + architect(s) bus.
Post a Comment