Id#11945

Name #syedzaheerali shah

Program #BSSE

second semester
PAIR PROGRAMING .:-

Although it’s one of the oldest practices in agile development, pair programming is less common today
than other pillars of agile, such as scrum and iterative development.

Steve Smith, founder of Ardalis Services, a software development consulting company, and co-instructor
of a Pluralsight course on pair programming, told Built In that the practice originated as way to do
instant code reviews.

“It comes from extreme programming, which was one of the first agile practices that came about back in
the 1990s,” Smith said. “It’s well known that code reviews help find and reduce defects in code that
you’re shipping, and the sooner you discover a defect, the less expensive it is to fix. And so it makes
sense to do at least some amount of your new development in pairs.”

The original idea was that having another developer present during the development phase makes it
easier to catch and fix mistakes even while they are being made. But the benefits of pair programming
extend well beyond catching coding errors.

“The intent is to develop software more effectively,” Smith said.

PAIRING HELPS DEVELOPERS MAKE BETTER DESIGN CHOICES

Coding with another developer can be helpful during the design phase — particularly for complex
projects.

“When there’s design involved and you don’t know how to solve the problem yet, and you’re thinking
about the ways to solve the problem — which is most of real software development — it can make a lot
of sense,” Smith said. “You have someone that you can bounce ideas off of and help with things like:
‘What should I call this? How should we name this? What about using this design versus that design?’”
Software development can involve a great deal of decision-making at every step in the process, he said.
Even for development teams that follow the top-down waterfall methodology, where every
architectural detail is mapped out before any code is written, it’s hard to avoid making coding choices
during implementation.

“After you’ve got a complete specification of exactly how everything’s going to be done, then you just
throw it over the wall to some developers and they just code it up — works great in theory, but rarely
works like that in practice,” Smith said. “You’re uncovering new requirements as you’re implementing
things, you’re iterating rapidly.... One developer is worried about these few lines of code inside a
method inside a class, and, meanwhile, the other developer might be thinking: ‘OK, what other classes
do we have to modify as part of this change? What test cases might we need to right now?’”

When running into these choices, it can help to talk things through with another person. Pair
programming ensures that another developer is always available as a sounding board, and eliminates
any worries about disrupting another person’s flow.

“And so you save up these questions until you have some team meeting or you just don’t worry about it
and pick something — and now you’ve missed an opportunity to collaborate,” Smith said. “Maybe you
end up with a suboptimal solution, because your teammate knew a better way to do it but you never
talked to them.”