• Pair Programming

    Pair programming comes from the understanding that two heads are better than one. In pair programming, two developers share the duties of completing a user story task; the idea is that both developers have time at the keyboard. There’s a driver and a navigator. The driver is the one sitting at the keyboard typing in code, while the navigator is the one reviewing the code being written, thinking about how to code the next step, and guiding the driver down a focused path. At first, management is often skeptical of this idea. They think that productivity will be cut in half because you have two developers doing what one developer could do. In reality, productivity increases in the following areas:

    1. Programmers stay focused: While we may not like to admit it, developers tend to be easily distracted. If they are stumped with a problem they typically go to the web to find some inspiration. This inspiration time typically slides into checking Twitter or Facebook or reading the latest blogs. With pair programming, each programmer is held accountable to the other to stay focused on the task at hand. Besides, it’s easier to bounce ideas off one another and come up with a solution quicker.

    2. Increase the “bus factor:” When one developer works on a feature, he works in a silo. His knowledge is therefore “siloed,” leading to a “bus factor” of 1. This colorful term focuses attention on the question: If you get hit by a bus or leave the company, what happens? Typically someone else needs to get ramped up on the code, but that takes time. With pair programming, the “bus factor” is increased to 2, which makes maintaining the system easier because two people have the knowledge. Moreover, they can usually add new features more quickly than if they were siloed.

    Pair programming is typically a developer practice, but it can be extended (for instance) to having a business analyst and a developer sitting down together. They can discuss the tests to be written, so questions and ideas can be answered quickly.

    Source of Information : Pro Agile .NET Development with SCRUM


0 comments:

Leave a Reply