Pair Programming

Pair programming is an agile software development technique in which 2 developers pair up as a team working together at one workstation. Both have the same target and task to execute. One, the driver, writes the code while the other, the navigator or observer considers the “strategic” direction of the work, coming up with ideas for improvements and likely future problems to address. Developers switch the roles periodically. It takes up the name from extreme programming ; extreme coding since code is reviewed as each line is typed.

In past, the way I made sure of code quality was getting the code reviewed with peer. Infact code reviews is one of the best strategies of having clean code and pairing fits right in the spot allowing  to continuously review code as and when it is typed.

I have seen project suffering for reasons like people dropping of from project, falling sick or going for vacation. Moreover in traditional development, not all developers would be familiar with code base. Some might be an expert in understanding and supporting one feature and not have any clue about the rest, which creates a huge dependency and what if such person drops of the project? I am sure someone would pick it up and start working. The bigger problem here would be the seamless continuity of work which greatly impacts completion of the project or features on time because to begin with the developer don’t have any clue codebase, change impacts , etc. Pairing comes here for rescue by having shared knowledge and context enabling developers to continue work seamlessly.

With shared knowledge, on-boarding a new developer on the team seems to be a easy and quick task.

Pairing helps for the better design. The developers must negotiate a shared course of action when a conflict arises between them. In doing so, they consider a larger number of ways of solving the problem than a single programmer alone might do. This significantly improves the design quality of the program as it reduces the chances of selecting a poor method.

Pairing enhances and support personal development. It may be tips of programming language rules, coding standards, design patterns usage or overall system design. Not just technical skills, it also helps to develop some interpersonal skills like providing feedback, better communication or respecting each individual idea or solution.

Shared knowledge among the team helps for the collective ownership. Anyone could step into resolving bug or supporting feature. True team collaboration, whether it is taking the credit for the success or embracing the failure.

Pairing enhances the engagement and focus. Number of things that can interrupt or distract a developer working alone is huge. When you are  part of a pair, you become much more resilient to those interruptions because you’re both committed to the task at hand. You’re less likely to be interrupted by colleagues because they can clearly see that you and your partner are in flow, and you’ll more easily resist the temptation to check emails because you’re both committed to completing the task at hand

Pairing works great when combined with Test Driven Development (TDD), one of the practice of Extreme Programming

Common misconceptions

Pair programming halves the developer productivity which would be true if the hardest part of the job was typing. Pairing is more productive due to continuous code reviews which come up with better designs, make less mistakes, and make more people familiar with the code. All of these things offset having less people typing.

I dont need pairing because I know I wont like it . This might me initial hesitation without even trying the technique. I wasn’t comfortable when I started this but now it gives me lot of confidence when I pair on a task. Hours passively staring over someone’s shoulder in a corner cube isn’t pair programming. Make sure you have someone who really knows how coach you, so you can be sure you’re evaluating the real thing.

Its worth pairing only on complex code. How do we decide what is complex? Moreover a developer might be fixing good number of bugs or work on many chores in a day which is a good context to be lost. Going hybrid approach might bring team imbalance. For eg, no one wants to work on simple things. Its not good for any one person in a team to decide what is complex? Imposing or bossing around not good for team collaboration

I was lot hesitant when I first tried on pair programming on a task and didn’t knew the benefits it would bring on the table. After spending 6 months roughly, I feel lot more confident pairing on a task with a developer and feel confident about the solution provided. I am truly able to understand benefits of continuous review, shared knowledge, easy on-boarding, better design and quality, which works very good, both for business and development. My advice to developers or business is to go out and try adopting pair programming . I am sure it will change your perception on pair programming


R.N -Engineer






Test Driven Development

Test Driven Development known as TDD is a software development methodology aimed to derive the software design and implementation by writing tests first. Its a RED-GREEN-REFACTOR short cycle where

RED – write a test which fails the desired behaviour or function

GREEEN  – write minimal code to make the test pass

REFACTOR – eliminate duplication / improve design and re run test to make sure implementation doesn’t break

WHY for development?

  • Continuously gives feedback and confidence to developer that components works
  • Gives developer the freedom to mercilessly refactor the code and have the test run as safety net  to make sure all the components are working fine
  • Forces developer to think of software in terms of small units that can be written and tested independently and integrated together later leading to smaller, more focused classes, looser coupling and cleaner interfaces which eventually leads to modular and clean code
  • Test suite acts as living documentation which can’t go outdated. If one is unsure of how a class or library works they can refer the test cases.
  • Test suite is a regression safety net. For any new bug discovered, a test case is added and made sure when each successive test run, all previous bug fixes are verified
  • Reduced debugging time helping the developer to quickly go to the root of the problem 
  • Helps to streamline the git flow by running the test as part of continuous integration and make sure any new commit doesn’t break the existing code base

WHY for business?

  • Reduced production defects density as any possible bugs are more effectively uncovered in the early development stage
  • Support/maintenance costs are lowered
  • Helps to win customer confidence by having reduced production defects, low support cost and a great quality product
  • Increases the chances of customer retention
  • Increases the developer productivity by addressing bugs early in the development stage which is more important than production as latter is a costly flow cycle which involves – getting context of the bug, creating the fix, pass through QA and if all goes fine then going ahead to release and if not then the cycle repeats.

Some misconceptions about TDD

  • Is slow or consumes too much time.  Adding TDD to the picture could increase the overall time-estimates and can thus be viewed as a time-consuming process. However, TDD produces long term advantages by virtue of factors like reduced defects and low maintenance cost, outweighing short term time savings.
  • Covers everything – might not be true in all cases. Considering mobile applications, not everything could (or should) be tested on front end. It’s hard to TDD for device or OS specific features, UI discrepancies on devices having varying screen resolution & densities and accessibility which more of a manual testing through screen readers

To conclude, TDD is an advanced technique that uses unit tests to drive the design of software. It doesn’t replace traditional testing, instead it defines a proven way to ensure effective unit testing. My experience is that TDD works incredibly well in practice and it is something that all software development teams should consider adopting.