Tuesday, 12 August 2014

Pairing -- Effective tool for quality software

Pair programming or pairing in short is one of the many practices followed in agile software development where two people work together on the same piece of code. Usually a user story or a task is assigned to a pair of developers and they work together on its implementation on a single machine. One person is the driver who types the code and other is the navigator. There is no rule on who is the driver and who is the navigator but they should rotate roles frequently. 

Perks of pairing

  1. Code quality:- 

    When two people are trying to solve the same problem, they bring in their individual experiences and different approach to solve the problem. They question each other, discuss the details, brainstorm and then arrive at the best solution. This definitely improves the design and code quality as compared to an individual working alone.  A study has revealed that the code resulted out of pair programming has around 15% to 20% less defects than the code written by an individual.
  2. Individual learning:- 

    There is constant knowledge sharing happening while pairing. Pairs learn a great deal from each other, right from smaller keyboard shortcuts to design patterns there is a constant learning happening. Most of the time when two people pair, one is an expert in one area and other in another. For example, one person is a java script guru while other is  nosql expert and eventually when they pair they shower their blessings on each other.
  3. Elimination of human errors:-

    There are two pairs of eyes constantly looking at the code which eliminates human errors and silly mistakes are caught while programming. There is no scope of a person being lazy and taking shortcuts because there is another person sitting next to to him/her reviewing the code all the time.
  4. No knowledge pockets or dependencies created:-

    There is no dependency created on a single person. Every functionality is being implemented by a pair and with frequent pair rotations almost everyone in the team would have a fair idea of everything. There are no knowledge pockets created hence there is no need for a full fledged KT plan if a person is rolling off the project or leaving the organization.  There are definitely some module experts but continuously pairing with them spreads the knowledge across and pairing in itself is the best way of doing knowledge transfer.
  5. Increased productive time:- 

    People avoid unnecessary meetings and calls because they know their pair is waiting for them.  People are not usually pulled into distracting conversations if they are pairing which otherwise they would have. People don't waste time on social media, gaming or chatting while pairing but they still have someone to talk to in person all the time. It is being observed that people spend more productive hours while pairing rather than working alone. Along with this there is no dedicated time required for code review because as people pair they also review.

What pairing is not?

Many people/organizations have some misconception about pairing. Pairing is not where
  • one person implements and other reviews the code. 
  • two people distribute tasks among themselves and work individually.  
  • one person implements and explains the code and the other person listens.  
Pairing is where two people work simultaneously on the same piece of code where one is typing and other is reviewing and they switch roles frequently. Pairing is done on a single work station often known as a pairing machine.  Person who types the code is the driver and the one who reviews is the navigator and they switch roles frequently by taking the keyboard control. There is no rule on when to switch roles but it is advisable to switch on a logical break point. It is also recommended in one of the articles that not one person should not drive for more than 20 minutes. But again as I mentioned there is no hard and fast rule as long as people are switching roles.

Effective pairing combinations

To get maximum out of pairing, it is very important to have a proper pairing combination. It is advisable that an experienced developer pairs with a novice developer. This enhances the learning curve for the novice developer and provides mentoring opportunities for the experienced person. But then the experienced person should rotate pairs with someone who is more experienced than  him/her so that he/she also gets to learn and he/she is questioned and challenged enough. Sometimes it is also important that a novice person pairs with someone with same experience and similar skill set. This helps them explore more rather than just listening to the mentor. Hence, all the three pairing combinations are effective when used appropriately:-
Expert pairing with novice:- Most effective and most recommended.
Expert pairing with expert:- Most productive for complex features but an overkill for simple functionality.
Novice pairing with novice:- Advisable for simpler implementations with more learning space.

Pair Rotations:-  

One important aspect of pairing is frequent pair rotation. One person should not keep pairing with the same person for a long time. There is no defined time on when the pairs should rotate but it is always advisable at a logical point in the story or the functionality. Sometimes the stories are so small that the same pair can finish it but then ensure that they don't pair for the next story.  With proper pair rotations almost everyone in the team gets to work on the functionality and gets some idea around the code.

Who can pair? 

Developers pairing with developers is common and that is what pair programing is all about. Sometimes it is advisable for QAs to pair with each other while testing a complex module or automating functional tests. But along with this, some cross functional pairing is also very important and useful for delivering quality software.
  1. Developers pairing with QAs:-

    Developers can pair with QAs while writing unit and integration tests. QAs can help developers in terms of scenarios to be covered at unit and integration level. Also QAs get a hang of what is already covered at unit level so that they don't repeat the same scenarios during functional testing.
    Also, developers and QAs can pair while automating functional test (UI driven). Specially when there is a framework to be built for functional automation, developers can utilize their programming expertise and pair with QAs for initial implementation and then QAs can enhance there onwards.
  2. Developers pairing with BAs:-

    Some stories require some amount of technical analysis and at such situations BAs should pair with developers. BAs and developers pairing help BAs to understand the technical implications and feasibility of an application whereas developers come to know which way the requirements are going so that he/she can start thinking about the implementation in the same direction. BAs and developers pairing help in eliminating most of the last minute surprises.

  3. QAs pairing with BAs:-

    BAs and QAs should pair while writing acceptance criteria for a story and also while designing test cases. QA mindset of breaking the application can help BAs to come up with the negative acceptance criteria. While BAs can help QAs to understand the business relevance and prioritization of test cases based on business value.

    People might find pairing costly but it is definitely way cheaper than fixing  production defects and sometimes even bringing the system down. It is like saying I cannot afford insulating the wires but I can bear the consequences of an electric shock.


1 comment:

  1. Liked conclusion :People might find pairing costly but it is definitely way cheaper than fixing production defects and sometimes even bringing the system down. It is like saying I cannot afford insulating the wires but I can bear the consequences of an electric shock.