Posts tagged ‘agile’
Two heads are better than one
Pair programming is an agile concept and is frequently used in XP (eXtreme Programming). At its core, it is nothing but having two people sit and code instead of one. And while that may seem like an obvious timesink and a doomed concept, considering two people cannot type and code at the same time, it is surprisingly effective for many reasons, some of which I will try to outline with examples from my brief experience.
When you work as part of a team, there is usually a process (sometimes a series of flaming hoops even) which you have to jump through before you can submit your new, super amazing, code which breaks all previous latency records. Or something just as amazing. And for a lot of groups, that involves a code review process, where someone familiar with the architecture of the system or understands the programming language and the problem goes through your code, points out issues (as if there are any in my code !!!) and so on. And while this is a good way to ensure that the quality of code that is submitted to your code base remains above a certain threshold, it becomes a huge timesink. Especially the more you know about the codebase, as everyone and their aunts start sending code reviews your way.
How is this solved with pair programming, you ask ? Well, consider this. While pair programming, assuming one guys starts coding away. What does the other guy do ? He (aha, you shout, as you understand even before I say it) reviews the code as you type, suggesting corrections and optimal solutions in case you start going down the wrong route. But then, you ask, isn’t that a huge waste of time, considering you are basically getting one person to just sit and permanently review ?
Here is where the beauty of pair programming really shines. Its called pair programming for a reason. For one, both programmers take turns in writing up new code, while the other looks on and makes sure the code is up to the amazingly high standards. Another, how many times have you written this super awesome function which took you half an hour to think of, only to find someone tell you in a code review to use this existing library function that does the entire same thing ? Now imagine that guy is, instead, sitting right next to you and telling you this before you even start coding this up.
Furthermore, what if I am a new guy joining a team with a very stable, settled code base. How do I hit the deck running, other than sitting for hours reading up on documentation ? Well, I go find a senior guy who loves pair programming (which is easier than it sounds if a team loves Agile practices) and go pair with him. Instant knowledge dump, and easier transition. This was the case with Arthur, a guy who joined our group for a short period of time. Instead of spending, say two weeks reading design and architecture documents, we started pairing with him from day one. By the end of day three, he had already fixed two bugs (both of which were on the first day itself!!!) and had made quite some headway into designing his first full feature. Now this intensive pairing (some might even call it hand holding) might have caused us to loose some productivity in the first few days, but by the 4th day, we had a new engineer who was capable of working independently if need be while pairing on the initial designs and features.
Also, Pair programming helps increase discipline and productivity. How you ask ? Well, I tend to loose focus quite easily, and love to be caught up on my emails (the thousands that spam me everyday, sigh!). And replying to my IMs takes precedence, often interrupting my thought process. Now I was pairing on the other hand, out of respect to my pair, I usually end up closing all such external annoyances, and often get two to three hours of uninterrupted work. Does wonders for my productivity, which is why I often roam around look for people to pair with.
Of course, if you need to convince management why you need to do pair programming, you need but point them at the multitude of studies that have been done which show an increased quality in software developed while pairing as compared to individuals. Also, if a person ever does end up leaving the team, there is someone on the team left who has paired with him and thus there are no systems which are alien to everyone on the team ever. And hey, its fun to pair, think out loud and bounce ideas off of each other. Seemingly impossible problems may seem easier as well when you pair. Often times, I seek out a teammate to bounce ideas off of, and more often than not, he will say “Alrite, let me get my keyboard. Lets pair on this.” Then it would take two hours to churn it out, and we would have a working, tested prototype by the end of it.
Of course, on the other hand, there is the intimidation factor of pairing with someone who seems much more knowledgeable and would eat you for lunch. Not to mention possible ego clashes and the fact that some people might find it akin to tutoring if they are paired with someone new. But these are pitfalls that can be overcome quite easily with a dedicated team.
And pair programming works really great when you do Test Driven Development. TDD is the art of writing a failing test before going and writing just the amount of code to pass the test. When you practice something known as ping pong pair programming with TDD, it becomes quite interesting and fun. In this, one person writes a failing test, and then the other person goes and writes the bare minimum code to get the test to pass (That is the key, the bare minimum. Don’t do speculative programming). And then, they switch. So the guy who wrote the code the first time now writes the next test, and the other person implements the functionality. This ensures that both people get turns at writing code and tests, and can make sure they cover all the cases. You end up with well tested code, but just enough code for your need. No speculation, no unneeded generalization, nothing extra.
And of course, no agile practice post is complete without an obligatory dilbert comic, so here goes :
Assertion Failed!! 