How to improve Quality with Pair Programming? – Part 2 of 2

In our earlier blog, we discussed why to go for pair programming, how to implement pairing in your organization, what makes a pair operationally strong, pair combinations and pair variations.

Considerations before applying Pair Programming:

• Planning: Include finance plan, resource plan, technology plan, and strategic plan. Linking of business goals with the project, overall operations planning and addressing issues to execute the project plan. Do not forget to do contingency planning. These plans will succeed if made in view of pair programming. A separate pairing plan can be highly beneficial. Most importantly, if your plan for pairing is ready, share the document with the team.

• Resources and Preparation: Check if the project needs two resources to work on it.
  • Who and why are you pairing the selective developers? The management and the developers both should be aware of the selection. The developers will know the reason for team up and management will know what this exact combination can deliver.
  • Prepare them to work together: Inexperienced developers may have a hard time coping with the experienced ones. Senior developers feel the pressure of mentoring the newbies and might impact their mindset. Help them prepare to work as a pair.
  • Do they have the required skills? Every project needs different skillsets and resources. Having people on team who are trained and are technology experts is added advantage.
  • Have they understood the requirement? If not set aside some time to meet them, discuss their individual goals and goals as a team. Bring clarity on the task ownership and shared responsibilities.

• What should they focus on? The customer expectation, innovative solution or quality software are the main criteria. Other than this the maintainability of code, quality of code, smaller codes etc. is what developers can bring to the project through their experience.
  • What is the expected outcome? The 24×7 availability of software, ease of use, lighter pages, and customers desire for faster query processing. Joint efforts and learning by the end of the project should add to existing skillsets as individuals.
  • Have they worked with each other earlier? The rapport can create wonders. If they have been on a project together or at least in the same team it certainly improves understanding and communication. The awkwardness between the pair because of unsaid things or just being new to each other is a difficult phase.
  • Do they have people skills? Any and every job on this earth needs people skills no doubt at distinct levels. People skills increases the ability to relate to others, trust them, express interest, and flexibility in approach. Patience, good judgement, and active listening are keys to effective problem-solving.

• Actions of Pairing Partners: The partners should try and know each other to know the level of clarity they have on the project. Shorter meetings allow the developers helps them get comfortable with each other. To plan coding, they can chalk out the expectations from the role (driver/navigator), and how they will fit in it. They need to figure out the internal and external deliverables.
  • Internal deliverables are with the developer’s and team’s rights.
    •   What is to be coded and is there any timeline attached? Developers should plan for the type of coding and activities attached. Creating codes that have minimum flaws that reduce testing time. Timely actions do enhance the abilities to manage a project.
    • Follow the Plan: The sensitivity of the plan and its execution is a team effort. The developers can break into smaller activities to manage coding efficiently.
    • Thought on probable issues: Pair working together should have some idea of the forthcoming issues. The issues can be of technical, professional or of personal level.
    • Learnings: Pair needs to enjoy this learning phase then only they can maintain the creativity quotient. Keeping excitement alive makes the journey of paired programming enjoyable.
  • External deliverables are in the periphery of management. It includes budgeting, scheduling, discussion with stakeholders, reporting and reviews.

• Reporting Structure: Reports are the easiest means of finding the current status of a project.
  •    Is work allocation sorted?  Yes, this is relevant as allocation has a direct impact on the progress of a project, its reporting, and deliverables.
  • Tracking progress: How do you intend to track progress, weekly meetings, or any other reporting tools in use. Tools make it easy to monitor and analyze tasks, its duration and even get into the loop of various stages of a project.
  • Handover: Internally when developers are replaced or resources leave the organization a standard procedure smoothens handover. Prepare for the final handover to the user, define structure and timelines for introducing the application, training and finally supply the release documentation. 

Pair programming Benefits:

• Pairing reduces pressure built on a single programmer and joint efforts fetch quality codes.
• Organizations get two thinking caps instead of one to focus on development for a context.
• Overcoming the differences eases as developers can switch roles from driver to navigator and keep their interests high.

• You encounter fewer defects than individual programmer may produce.
• Faster detection of coding mistakes saves time on recoding.
• Immediate bug fixing reduces the costs of testing an application.
• Focused discussions and casual review formats make a greater impact.
• Skill development, knowledge sharing and mutual learning improve teamwork.
• Team efforts help to achieve higher efficiency and faster problem-solving.
• Create simple and manageable codes/applications reduce issue resolution expenses
• Pair gets to work on live project and increases their confidence levels 
• Polish communication skills help to produce better solutions
• Get work in progress status updates from any one of the pair
• No need for separate review meetings accelerates programming.
• Evaluation of solutions prior to implementation.

Challenges of Pair programming:

• Both the developers have to rely on their partner for support, which can complicate simple tasks.
• Complete dependency is on the observer for the review of code is a bit of a threat. A reviewer may overlook the bugs due to monotonous work.
• If the reviewer doesn’t warn the driver of the ambiguities paired programming can be a total failure.
• Lack of willingness to work as a pair and not so amicable nature can lead to disagreements.
• Inability to work as a pair can hamper the role developer is playing. The same is the case if the pairing partner doesn’t play fair or clean their mess.
• Human moods/ego of driver or navigator affects the quality of communication.
• Skill, intelligence, understanding, and personality mismatch creates an adverse effect
• Finding the correct combination of resources for a project e.g., two strong developers may not be good pair in a project where the customer expects flexibility and frequent requirement changes
• Pattern of work if not same of both the developers, it can cause quality issues
• Lack of task understanding and ownership or being unable match to each other’s speed can downgrade their performance.
• If both of them focus on different issues or have dissimilar thoughts on the probable solution or enmesh in unnecessary discussions over the probable solution then it is unfavorable.
• At times freedom of creativity is somewhere compromised so the project manager should keep them motivated.
• Self-learning may become a lost virtue.

How to make Pair Programming work?

Define tasks before the coding starts, let the pair agree on a line of action. They should set their goals. Foremost is that they should not feel like inseparable twins.  Do not bind them to work together for 100% of the daytime. Every developer needs to spend time with themselves or has to try out few things before he/she suggests to the partner.

Companies get too rigid with the office and break timings, leaves etc… Don’t expect them to innovate solutions when confined in a box. Freedom of expression, working comfortability and letting the pair find their equation of working together.

Allow them to seek help if the pair is stuck. Initially, the paired programmers may need some support. It may not be fair to make them tackle issues just because you think they are a team of two and should produce better results than coding independently.

Even though you are keen on experimentation do not apply everything to a project. Rate the performance of individual and as a pair.

Productivity by pairing:

The productivity of a pair cannot shoot up in just a few days. In the beginning, you may come across a decline in productivity by about 15%. It is not a concern as recovery in long term camouflage by improved performance of the pair.

They will try and match the style or work at a low speed to code perfectly and reduce errors. A developer individually, as well as a pair, contributes to the project. Let the game catch a pace before you react or start worrying over the budget.

If you find continued productivity issues look into what needs to change within the pair. Is it the hours of work, is it their style of coding or any overlooked reviewing sections? Assumptions will not lead you anywhere. The pair may not have sufficient knowledge or have different expertise.

Effects of pairing quality-wise: Issues of overshadowed personalities, ignored facts, clear understanding of user requirements and lack of efforts have a direct impact on quality. Readiness to embrace challenges empowers paired programmers. Quality is a result of those imperfect moments developers overcome.

Impact of pairing on duration:

Keep a watch on the number of tasks picked by the developers. Check the work in progress to get hang of pending tasks. The time consumed to achieve the defined tasks provides clarity on efficiency. You can introduce required precautions to minimize the surplus time used by the pair.

How to measure Pair Programming?

If the progress of a project is delayed by say 10% and near to delivery if you encounter 10% lesser defects, it’s a win-win situation. 

Listed here are a few measurable things:

• Time spent in development and fixing bugs
• Enrich experience in innovating solutions
• Capabilities grew with mutual learning
• Improved coding as a result of better teamwork
• Superior results of collective ownership
• Reduced efforts of a testing team
• Progressed team knowledge
• Market delivery in a short period
• Positive customer feedback

The pros and cons will ease decision making for when to pair and when not to. Using the experienced resources wisely to spread across the current projects is favorable. Choose to rotate the pairs as needed.

In experiments by the University of Utah, pairs spend 15% more time on programming than working independently. You can certainly await better performing software.

Conclusion

Pair programming ensures continuous delivery even in absence of a developer from the pair. Numerous studies depict a tremendous increase in productivity. Success comes to those who work smart and try new development techniques.

If you want to find out more, please get in touch with us anytime at Contact Us