Extreme programming

Extreme & Pair Programming

Extreme Programming

What is Extreme Programming? (XP)

Extreme Programming (XP) is a software engineering methodology, the most prominent of
several agile software development methodologies. Like other agile methodologies, Extreme
Programming differs from traditional methodologies primarily in placing a higher value on
adaptability than on predictability. Proponents of XP regard ongoing changes to requirements as
an often natural and often inescapable aspect of software development projects; they believe that
being able to adapt to changing requirements at any point during the project life is a more
realistic and better approach than attempting to define all requirements at the beginning of a
project and then expending effort to control changes to the requirements. XP prescribes a set of
day-to-day practices for managers and developers; the practices are meant to embody and
encourage particular values. Proponents believe that the exercise of these practices—which are
traditional software engineering practices taken to so-called "extreme" levels—leads to a
development process that is more responsive to customer needs ("agile") than traditional
methods, while creating software of similar or better quality.

Origins

Software development in the 1990s was shaped by two major influences: internally, object-
oriented programming replaced procedural programming as the programming paradigm favored
by some in the industry. Rapidly-changing requirements demanded shorter product life-cycles,
and were often incompatible with traditional methods of software development.Various
contributors discussed and expanded upon the ideas, and some spin-off methodologies resulted
(see agile software development). Also, XP concepts have been explained, for several years,
using a hyper-text system map on the XP website.

Current state

XP created quite a buzz in the late 1990s and early 2000s, seeing adoption in a number of
environments radically different from its origins. The high discipline required by the original

1


practices often went by the wayside, causing certain practices to be deprecated or left undone on
individual sites. Agile development practices have not stood still, and XP is still evolving,
assimilating more lessons from experiences in the field.

Goal of Extreme Programming

Extreme Programming is described as being:

• An attempt to reconcile humanity and productivity
• A mechanism for social change
• A path to improvement
• A style of development
The main aim of XP is to lower the cost of change. In traditional system development methods
(like SSADM) the requirements for the system are determined at the beginning of the
development project and often fixed from that point on. This means that the cost of changing the
requirements at a later stage will be high. XP sets out to lower the cost of change by introducing
basic values, principles and practices. By applying XP, a system development project should be
more flexible with respect to changes.

Extreme Programming values

Extreme Programming initially recognized four values. A new value was added in the second
edition of Extreme Programming Explained. The five values are:

• Communication
• Simplicity
• Feedback
• Courage
• Respect
Building software systems requires communicating system requirements to the developers of the
system. In formal software development methodologies, this task is accomplished through
documentation. Extreme Programming techniques can be viewed as methods for rapidly building
and disseminating institutional knowledge among members of a development team. The goal is
to give all developers a shared view of the system which matches the view held by the users of
the system. To this end, Extreme Programming favors simple designs, common metaphors,

2


collaboration of users and programmers, frequent verbal communication, and feedback.

Extreme Programming encourages starting with the simplest solution and refactoring to better
ones. The difference between this approach and more conventional system development methods
is the focus on designing and coding for the needs of today instead of those of tomorrow, next
week, or next month. Proponents of XP acknowledge the disadvantage that this can sometimes
entail more effort tomorrow to change the system; their claim is that this is more than
compensated for by the advantage of not investing in possible future requirements that might
change before they become relevant. Coding and designing for uncertain future requirements
implies the risk of spending resources on something that might not be needed. Related to the
"communication" value, simplicity in design and coding should improve the (quality of)
communication. A simple design with very simple code could be easily understood by most
programmers in the team.

Within Extreme Programming, feedback relates to different dimensions of the system
development:

Feedback from the system

by writing unit tests, or running periodic integration tests, the programmers have direct
feedback from the state of the system after implementing changes.

Feedback from the customer

The functional tests (aka acceptance tests) are written by the customer and the testers. They
will get concrete feedback about the current state of their system. This review is planned
once in every two or three weeks so the customer can easily steer the development.

Feedback from the team

When customers come up with new requirements in the planning game the team directly
gives an estimation of the time that it will take to implement.

Feedback is closely related to communication and simplicity. Flaws in the system are easily
communicated by writing a unit test that proves a certain piece of code will break. The direct

3


feedback from the system tells programmers to recode this part. A customer is able to test the
system periodically according to the functional requirements (aka user stories). To quote Kent
Beck, "Optimism is an occupational hazard of programming, feedback is the treatment."

Several practices embody courage. One is the commandment to always design and code for
today and not for tomorrow. This is an effort to avoid getting bogged down in design and
requiring a lot of effort to implement anything else. Courage enables developers to feel
comfortable with refactoring their code when necessary. This means reviewing the existing
system and modifying it so that future changes can be implemented more easily. Another
example of courage is knowing when to throw code away: courage to remove source code that is
obsolete, no matter how much effort was used to create that source code. Also, courage means
persistence: A programmer might be stuck on a complex problem for an entire day, then solve
the problem quickly the next day, if only he or she is persistent.

The respect value manifests in several ways. In Extreme Programming, team members respect
each other because programmers should never commit changes that break compilation, that make
existing unit-tests fail, or that otherwise delay the work of their peers. Members respect their
work by always striving for high quality and seeking for the best design for the solution at hand
through refactoring.

Principle Of Extreme Programming

The principles that form the basis of XP are based on the values just described and are intended
to foster decisions in a system development project. The principles are intended to be more
concrete than the values and more easily translated to guidance in a practical situation.

Feedback is most useful if it is done rapidly. The time between an action and its feedback is
critical to learning and making changes. In Extreme Programming, unlike traditional system
development methods, contact with the customer occurs in small iterations. The customer has
clear insight into the system that is being developed. He or she can give feedback and steer the
development as needed.

Unit tests also contribute to the rapid feedback principle. When writing code, the unit test
provides direct feedback as to how the system reacts to the changes one has made. If, for

4


instance, the changes affect a part of the system that is not in the scope of the programmer who
made them, that programmer will not notice the flaw. There is a large chance that this bug will
appear when the system is in production.

Simplicity is about treating every problem as if its solution were extremely simple. Traditional
system development methods say to plan for the future and to code for reusability. Extreme
programming rejects these ideas.

The advocates of Extreme Programming say that making big changes all at once does not work.
Extreme Programming applies incremental changes: for example, a system might have small
releases every three weeks. By making many little steps the customer has more control over the
development process and the system that is being developed.

The principle of embracing change is about not working against changes but embracing them.
For instance, if at one of the iterative meetings it appears that the customer's requirements have
changed dramatically, programmers are to embrace this and plan the new requirements for the
next iteration.

Extreme Programming Life Cycle
Extreme Programming is an agile method of software development focused on providing the
highest value for the customer in the fastest way possible. Read on for an understanding of the
extreme programming life cycle and how it can benefit you. The traditional software
development process is linear, with each stage of the lifecycle requiring completion of the
previous stage. For instance, design starts only on completion of the entire analysis of the
program, and coding starts only after completion and freezing of the design. This concept works
well when customer requirements remain static, but in practice, requirements change frequently
and cause frequent editing of programs leading to errors and software ‘rot.’

Extreme Programming (XP) turns the traditional software development process sideways. Rather
than planning, analyzing, and designing in a linear fashion, XP programmers do all such
activities a little at a time throughout the development phase. The approach bears resemblance to
a jigsaw puzzle with the development of many small pieces or iterations that make no sense

5


individually, but making for a complete package when combined. The biggest advantage of this
approach is the resilience it provides, allowing for easy incorporation of changes.

The Extreme Programming software development process starts with planning, and all iterations
consist of four basic phases in its life cycle: designing, coding, testing, and listening. The
overriding values that drives the XP life cycle are continual communication with the customer
and amongst the team, simplicity by harping on the minimalist solution, frequent feedback
through unit and acceptance testing, and the courage to take on problems proactively and
integrate testing and changes in the development phase.

Planning

The first phase of Extreme Programming life cycle is planning, where customers or users meet
with the development team to create ‘user stories’ or requirements. The development team
converts user stories into iterations that cover a small part of the functionality or features
required. A combination of iterations provides the customer with the final fully functional
product. The programming team prepares the plan, time, and costs of carrying out the iterations,
and individual developers sign up for iterations. One planning approach is the critical path
method, grouping iterations essential for project progress in a linear fashion, and arranging for
completion of other iterations parallel to the critical path.

Designing

An iteration of XP programming starts with designing. The guiding principles of this stage are:

Thrust on simplicity by expressing a thing only once and not adding functionality in

6


anticipation. Using systems metaphor or standards on names, class names and methods, and
agreeing on uniform styles and formats to ensure compatibility among the work of different
team members. Using Software Class Responsibilities and Collaboration (CRC) Cards that
allow for a departure from the traditional procedural mindset and make possible object oriented
technology. Such cards allow all members of the project team to contribute ideas, and collate
the best ideas into the design. Creating spike solutions or simple programs that explore
potential solutions for a specific problem, ignoring all other concerns, to mitigate risk.

Coding

Coding constitutes the most important phase in the Extreme Programming life cycle. XP
programming gives priority to the actual coding over all other tasks such as documentation to
ensure that the customer receives something substantial in value at the end of the day.

Standards related to coding include:

Developing the code based on the agreed metaphors and standards, and adopting a policy of
collective code ownership. Pair programming or developing code by two programmers working
together on a single machine, aimed at producing higher quality code at the same or less cost.

Strict adherence to 40-hour workweeks with no overtime. This ensures the developers work in
the peak of their mental and physical faculties. Frequent integration of the code to the dedicated
repository, with only one pair integrating at a time to prevent conflicts, and optimization at the
end.

Testing

Extreme program integrates testing with the development phase rather than at the end of the
development phase. All codes have unit tests to eliminate bugs, and the code passes all such unit
tests before release. Another key test is customer acceptance tests, based on the customer
specifications. Acceptance test run at the completion of the coding, and the developers provide
the customer with the results of the acceptance tests along with demonstrations.

7


Listening

The basis of extreme programming is a continuous mechanism of customer involvement through
feedback during the development phase. Apart from the customer, the developer also receives
feedback from the project manager.The basis of feedback is the customer acceptance tests. Each
feedback of the customer that specifies revised requirement becomes the basis of a new design,
and the process of design-coding-tests-listening repeats itself. If the customer remains satisfied
with the test results the iteration ends there, and the design for the new iteration starts, which
again follows the design-coding-testing-listening cycle.

Extreme Programming Practices

Extreme Programming has 12 practices, grouped into four areas, derived from the best practices
of software engineering:

Extreme Programming Practices: Whole Team

• All contributors to an XP project are one team.
• Must include a business representative--the ‘Customer’.

Provides requirements.

Sets priorities.

8


Steers project.

• Team members are programmers, testers, analysts, coach, manager.
• Best XP teams have no specialists.

Extreme Programming Practices: Planning Game

• Two key questions in software development:

Predict what will be accomplished by the due date

Determine what to do next

• Need is to steer the project
• Exact prediction (which is difficult) is not necessary
• XP Release Planning

Customer presents required features

Programmers estimate difficulty

Imprecise but revised regularly

• XP Iteration Planning

Two week iterations

Customer presents features required

Programmers break features down into tasks

Team members sign up for tasks

Running software at end of each iteration

Extreme Programming Practices: Customer Tests

• The Customer defines one or more automated acceptance tests for a feature
• Team builds these tests to verify that a feature is implemented correctly
• Once the test runs, the team ensures that it keeps running correctly thereafter

9


• System always improves, never backslides

Extreme Programming Practices: Small Releases

• Team releases running, tested software every iteration.
• Releases are small and functional.
• The Customer can evaluate or in turn, release to end users, and provide feedback.
• Important thing is that the software is visible and given to the Customer at the end of every
iteration.

Extreme Programming Practices: Simple Design

• Build software to a simple design.
• Through programmer testing and design improvement, keep the software simple and the
design suited to current functionality.
• Not a one-time thing nor an up-front thing.
• Design steps in release planning and iteration planning.
• Teams design and revise design through refactoring, through the course of the project.

Extreme Programming Practices: Pair Programming

• All production software is built by two programmers, sitting side by side, at the same
machine
• All production code is therefore reviewed by at least one other programmer
• Research into pair programming shows that pairing produces better code in the same time
as programmers working singly
• Pairing also communicates knowledge throughout the team

Extreme Programming Practices: Test-Driven Development

• Teams practice TDD by working in short cycles of adding a test, and then making it work
• Easy to produce code with 100 percent test coverage
• These programmer tests or unit tests are all collected together
• Each time a pair releases code to the repository, every test must run correctly

10


Extreme Programming Practices: Design Improvement

• Continuous design improvement process called ‘refactoring’:

Removal of duplication

Increase cohesion

Reduce coupling

• Refactoring is supported by comprehensive testing--customer tests and programmer tests

Extreme Programming Practices: Continuous Integration

• Teams keep the system fully integrated at all times
• Daily, or multiple times a day builds
• Avoid ‘integration hell’
• Avoid code freezes

Extreme Programming Practices: Collective Code Ownership

• Any pair of programmers can improve any code at any time
• No ‘secure workspaces’
• All code gets the benefit of many people’s attention
• Avoid duplication
• Programmer tests catch mistakes
• Pair with expert when working on unfamiliar code

Extreme Programming Practices: Coding Standard

• Use common coding standard
• All code in the system must look as though written by an individual
• Code must look familiar, to support collective code ownership

Extreme Programming Practices: Metaphor

• XP Teams develop a common vision of the system

11


• With or without imagery, define common system of names
• Ensure everyone understands how the system works, where to look for functionality, or
where to add functionality

Extreme Programming Practices: Sustainable Pace

• Team will produce high quality product when not overly exerted.
• Avoid overtime, maintain 40 hour weeks.
• ‘Death march’ projects are unproductive and do not produce quality software.
• Work at a pace that can be sustained indefinitely.

Extreme Programming Values

Communication
Simplicity
Feedback
Courage
XP Values: Communication

• Poor communication in software teams is one of the root causes of failure of a project.
• Stress on good communication between all stakeholders--customers, team members,
project managers.
• Customer representative always on site.
• Paired programming.

XP Values: Simplicity

• ‘Do the Simplest Thing That Could Possibly Work’.

Implement a new capability in the simplest possible way.

Refactor the system to be the simplest possible code with the current feature set.

• ‘You Aren’t Going to Need It’

Never implement a feature you don’t need now.

12


XP Values: Feedback

• Always a running system that delivers information about itself in a reliable way
• The system and the code provides feedback on the state of development
• Catalyst for change and an indicator of progress

XP Values: Courage

• Projects are people-centric
• Ingenuity of people and not any process that causes a project to succeed

Extreme Programming Criticism

• Unrealistic--programmer centric, not business focused
• Detailed specifications are not written
• Design after testing
• Constant refactoring
• Customer availability
• 12 practices are too interdependent

Application of Extreme Programming

Extreme Programming remains a sensible choice for some projects. Projects suited to Extreme
Programming are those that:

Involve new or prototype technology, where the requirements change rapidly, or some
development is required to discover unforeseen implementation problems
Are research projects, where the resulting work is not the software product itself, but domain
knowledge are small and more easily managed through informal methods.

Projects suited for more traditional methodologies are those that:

Involve stable technology and have fixed requirements, where it is known that few changes will
occur Involve mission critical or safety critical systems, where formal methods must be

13


employed for safety or insurance reasons Are large projects which may overwhelm informal
communication mechanisms Have complex products which continue beyond the project scope to
require frequent and significant alterations, where a recorded knowledge base, or documentation
set, becomes a fundamental necessity to support the maintenance

Project Managers must weigh project aspects against available methodologies to make an
appropriate selection.

Conclusion
High ceremony’ software engineering methodologies in disfavor Agile software development
methodologies in increasing use, but with significant criticism Formal methods will never have a
significant impact until they can be used by people that don’t understand them.

14


Pair Programming
Pair programming has become popular word among software developers recently. As the name
suggests, pair programming is a software development activity (writing code) which is done by
two programmers. There will be only one of them writes the code and the other programmer
thinks whether the code written satisfy their goals. The idea is similar with rallying where in one
car there are two people. They are the driver and co-driver. The driver will drive the car and the
co-driver will guide the driver to drive accurately.

Pair programming is a programming technique adopted by extreme programming or any agile
software development methodologies. Some people argue that this method is a good practice. On
the other hand, there are many people say that it is sorrowful. In this blog, the benefits and
drawbacks of pair programming will be analyzed, to understand whether pair programming is
painful or not.

Some benefits of pair programming are efficiency and increase in performance. In term of
efficiency, we can cut the number of workstations as well as software licenses since we need
only one workstation every two developers. However, the main advantage that people looking
for in this programming approach is an improvement in developer performance. This includes an
increase on the number of line of codes and reduced number of bugs or defects in the written
code. This can be achieved, because one of the programmers can concentrate to write the code
and another one analyzes the code which is written on the screen. If there is something wrong
with the code, there is a big chance that it will be spotted during the development phase.

Although pair programming promises wonderful benefits for developers, it has some drawbacks.
I believe most people will feel awkward, if they are watched by someone else when they are
working. That is why we can find cubicles in many working places. Some people find that it is
hard to work under tight supervision. The other problem is every human has their own style and
way of thinking. This is also applied in coding style and logical flow within our source code. In
my opinion, it is difficult to understand other programmer’s code or adopt their styles, especially
if there is a big different in the experience and programming skills.

15


All of the drawbacks of pair programming are most likely caused by unmatched programmer
being paired. I believe this can be solved if both programmer can get a long together and have
the same level of programming skills. It will be better if both programmers come from the same
programming language background since there is a big probability they will have same
programming styles. It is not an easy task to pair up developers in a project.

Introduction
Pair programming is a style of programming in which two programmers work side-by-side at one
computer, continuously collaborating on the same design, algorithm, code or test. As discussed
below, use of this practice has been demonstrated to improve productivity and quality of
software products. Additionally, based on a survey (Williams 1999) of pair programmers
(hereafter referred to as “the pair programming survey"), 100% agreed that they had more
confidence in their solution when pair programming than when they program alone. Likewise,
96% agreed that they enjoy their job more than when programming alone.

However, most programmers are long conditioned to performing solitary work and often resist
the transition to pair programming. Ultimately, most triumphantly make this transition. This
purpose of this paper is to aid programmers in becoming effective pair programmers. The
transition and on-going success as a pair programmer often involves practicing everyday civility,
as written about in Robert Fulghum’s poem above. Each of the poem lines (some adapted with
poetic license) will be explored for the inherent lessons related to successful pair programming.

Pair Programming: Evidence of Success
Anecdotal and initial statistical evidence indicates pair programming is highly beneficial.
Extreme Programming (XP), an emerging software development methodology, attributes great
success to the use of “pair programming.” XP was developed initially by Smalltalk code
developer and consultant Kent Beck with colleagues Ward Cunningham and Ron Jeffries. The
evidence of XP’s success is highly anecdotal, but so impressive that it has aroused the curiosity
of many highly-respected software engineering researchers and consultants. The largest example
of its accomplishment is the sizable Chrysler Comprehensive Compensation system launched in
May 1997. After finding significant, initial development problems, Beck and Jeffries restarted

16


this development using XP principles. The payroll system pays some 10,000 monthly-paid
employees and has 2,000 classes and 30,000 methods, (Anderson 1998), went into production
almost on schedule, and is still operational today. Additionally, programmers at Ford Motor
Company, spent four unsuccessful years trying to build the Vehicle Cost and Profit System
(VCAPS) using a traditional waterfall methodology. The XP developers successfully
implemented that system in less than a year using Extreme Programming (Beck 1999).
XP attributes great success to the use of “pair programming.” All production code is written with
a partner. XP advocates pair programming with such fervor that even prototyping done solo is
scrapped and re-written with a partner. One key element is that while working in pairs a
continuous code review is performed, noting that it is amazing how many obvious but unnoticed
defects become noticed by another person watching over their shoulder. Results (Beck 1999)
demonstrate that the two programmers work together more than twice as fast and think of more
than twice as many solutions to a problem as two working alone, while attaining higher defect
prevention and defect removal leading to a higher quality product. Two other studies support the
use of pair programming. Larry Constantine, a programmer, consultant, and magazine columnist
reports on observing “Dynamic Duos” during a visit to P. J. Plaugher’s software
company, Whitesmiths, Ltd, providing anecdotal support for collaborative programming. He
immediately noticed that at each terminal were two programmers working on the same code. He
reports, “Having adopted this approach, they were delivering finished and tested code faster than
ever . . . The code that came out the back of the two programmer terminals was nearly 100% bug
free . . . it was better code,tighter and more efficient, having benefited from the thinking of two
bright minds and the steady dialogue between two trusted terminal-mates . . . Two programmers
in tandem is not redundancy; it’s a direct route to greater efficiency and better
quality.”(Constantine 1995)
An experiment by Temple University Professor Nosek studied 15 full-time, experienced
programmers working for 45 minutes on a challenging problem, important to their organization,
in their own environment, and with their own equipment. Five worked individually, ten worked
collaboratively in five pairs. Conditions and materials used were the same for both the
experimental (team) and control (individual) groups. This study provided statistically significant
results, using a two-sided t-test. “To the surprise of the managers and participants, all the teams
outperformed the individual programmers, enjoyed the problem-solving process more, and had

17


greater confidence in their solutions.” The groups completed the task 40% more quickly and
effectively by producing better algorithms and code in less time. The majority of the
programmers were skeptical of the value of collaboration in working on the same problem and
thought it would not be an enjoyable process. However, results show collaboration improved
both their performance and their enjoyment of the problem solving process (Nosek 1998).
The respondents of the pair programming survey gave overwhelming support for the technique.
Says one: “I strongly feel pair programming is the primary reason our team has been successful.
It has given us a very high level of code quality (almost to the point of zero defects). The only
code we have ever had errors in was code that wasn’t pair programmed . . . we should really
question a situation where it isn’t utilized.” Given these successes, let's review some principles
of pair programming in the context of Fulghum’s poem.
Share everything.
In pair programming, two programmers are assigned to jointly produce one artifact (design,
algorithm, code, etc.). The two programmers are like a coherent, intelligent organism working
with one mind, responsible for every aspect of this artifact. One person is typing or writing, the
other is continually reviewing the work. But, both are equal participants in the process. It is not
acceptable to say or think things such as, “You made an error in your design.” or “That defect
was from your part.” Instead, “We screwed up the design.” or, better yet, “We just got through
test with no defects!” Both partners own everything.
Play fair.
With pair programming, one person “drives” (has control of the keyboard or is recording design
ideas) while the other is continuously reviewing the work. Even when one programmer is
significantly more experienced than the other, it is important to take turns “driving,” lest the
observer become disjoint, feel out of the loop or unimportant. The person not driving is not a
passive observer, instead is always active and engaged. “Just watching someone program is
about as interesting as watching grass die in a desert (Beck to be published).” In the pair
programming survey, approximately 90% stated that the main role of the person not typing was
to perform continuous analysis, design and code reviews. “When one partner is busy typing, the
other is thinking at a more strategic level – where is this line of development going? Will it run
into a dead end? Is there a better overall strategy?

18


Don’t hit your partner.
But, make sure your partner stays focused and on-task. Doubtlessly, a benefit of working in pairs
is that each is far less likely to “waste time” reading e-mail, surfing the web, or zoning out the
window – because their partner is awaiting continuous contribution and input. Additionally, each
is expecting the other to follow the prescribed development practices. “With your partner
watching, though, chances are that even if you feel like blowing off one of these practices, your
partner won’t . . . the chances of ignoring your commitment to the rest of the team is much
smaller in pairs then it is when you are working alone (Beck to be published).”
Summarized in the pair programming survey, “It takes more effort because the pace is forced by
the other person all the time; neither person feels they can slack off.” As each keeps their partner
focused and on task, tremendous productivity gains and quality improvements are realized.

Put things back where they belong.
The mind is a tricky thing. If you think about something enough, the brain will consider it a
truth. If you tell yourself something negative, such as “I’m a terrible programmer,” soon your
brain will believe you. However, anyone can control this negative self-talk by putting these
thoughts where they belong, in the trash can, every time they start to creep into their brain. The
surveyed pair programmers indicated that it was very difficult to work with someone who had a
great insecurity or anxiety about their programming skills. They tend to have“If I work with you,
you might find out I’ve never coded with exceptions” defensiveness about them. Programmers
with such insecurity should view pair programming as a means to improve their skill by
constantly watching and obtaining feedback from another. A survey respondent reflected, “The
best thing about pair programming for me is the continuous discussion gave me training in
formulating the thoughts I have about design and programming, thereby helping me reflect over
them, which has made me a better designer/programmer.” Indeed, two researchers surveyed 750
working programmers on coordination techniques in software development. The communication
technique with both the highest use and the highest value was “discussion with peers.” “The
standard response when one confronts a problem that cannot be solved alone is to go to a
colleague close by (Kraut 1995).” When pair programming, the “colleague close by” is
continuously available. Together the pair can solve problems they couldn’t solve alone and can
help improve each other’s skills. Also, negative thoughts such as “I’m an awesome programmer,

19


and I’m paired up with a total loser” should also find their place in the trash can, lest the
collaborative relationship be destroyed. None of us, no matter how skilled, is infallible and above
the input of another. John von Neumann, the great mathematician and creator of the von
Neumann computer architecture, recognized his own inadequacies and continuously asked others
to review his work. “And indeed, there can be no doubt of von Neumann's genius. His very
ability to realize his human limitation put him head and shoulders above the average programmer
today . . . Average people can be trained to accept their humanity -- their inability to function
like a machine -- and to value it and work with others so as to keep it under the kind of control
needed if programming is to be successful (Weinberg 1998).”

Clean up your mess.
Pair programmers cite that it is amazing how many obvious but unnoticed defects become
noticed by another person watching over your shoulder. Additionally, these defects can be
removed without the natural animosity that might develop in a formal inspection meeting.
Established software engineering techniques often stress the importance of defect prevention and
efficient defect removal. This “watch over the shoulder” technique, perhaps, epitomizes defect
prevention and defect removal efficiency.

Don’t take things too seriously.
“Ego-less programming,” an idea surfaced by Gerald Weinberg in The Psychology of Computer
Programming (recently re-reported in Weinberg 1998) a quarter of a century ago, is essential for
effective pair programming. According to the pair programming survey, excess ego can manifest
itself in two ways, both damaging the collaborative relationship. First, having a “my way or the
highway” attitude can prevent the programmer from considering others ideas. Secondly, excess
ego can cause a programmer to be defensive when receiving criticism or to view this criticism as
mistrust. In The Psychology of Computer Programming (Weinberg 1998), a true scenario about a
programmer seeking review of the code he produced is discussed. On this particular “bad
programming” day, this individual laughed at himself because his reviewer found seventeen bugs
in thirteen statements. However, after fixing these defects, this code performed flawlessly during
test and in production. How different this outcome might have been had this programmer been
too proud to accept the input of others or had viewed this input as an indication of his

20


inadequacies. Having another to continuously and objectively review design and coding is a very
beneficial aspect of pair programming. “The human eye has an almost infinite capacity for not
seeing what it does not want to see . . . Programmers, if left to their own devices, will ignore the
most glaring errors in their output -- errors that anyone else can see in an instant (Weinberg
1998)."Conversely, a person who always agrees with their partner lest create tension also
minimizes the benefits of collaborative work. For favorable idea exchange, there should be some
healthy disagreement/debate. Notably, there is a fine balance between displaying too much and
too little ego. Effective pair programmers hone this balance during an initial adjustment period.
Ward Cunningham, one of the XP founders and experienced pair-programmer, reports that this
initial adjustment period can take hours or days, depending on the individuals, nature of work
and their past experience with pair-programming.

Say you’re sorry when you hurt somebody while moving furniture.
In the pair programming survey, 96% of the programmers agreed that appropriate workspace
layout was critical to their success. The programmers must be able to sit side-by-side and
program, simultaneously viewing the computer screen and sharing the keyboard and mouse. In
the diagram below (from (Beck 1999)), layouts to the right are preferable to layouts on the left.
Extreme programmers have a “slide the keyboard/don't move the chairs” rule. Effective
communication, both within a collaborative pair and with other collaborative pairs, is paramount.
Without much effort, programmers need to see each other, ask each other questions and make
decisions on things such as integration issues, lest these questions/issues are often not discussed.
Programmers also benefit from “accidentally” overhearing other conversations to which they can
have vital contributions. Separate offices and cubicles can inhibit this necessary exchange. "If
any one thing proves that psychological research has been ignored by working managers, it's the
continuing use of half partitions to divide workspace into cubicles. … Like many kings, some
managers use divide-and-conquer tactics to rule their subjects, but programmers need contact
with other programmers. (Weinberg 1998)”
Pair programmers take aggressive action on improving their physical environment, by taking
matters into their own hands (armed with screwdrivers).
Inevitably, the pair programmers will work on something independently. Of the programmers
that were surveyed, over half said that when they rejoined with their partner, they reviewed this

21


independent work and then incorporated it into the project. Alternately, Extreme Programmers
flush and rewrite independent work. In their XP experience, the majority of the defects they
found could be traced back to a time when a programmer worked independently. In fact, in their
Chrysler Comprehensive Compensation project during the last five months before first
production, the only defects that made it through unit and functional testing were written by
someone programming alone. In re-writing, the author must undergo the customary continuous
review of the work, which identifies additional defects. The decision to flush or to review work
done independently can be made by a pair of programmers, or the choice may be encouraged, as
it is with Extreme Programming. However, it is important to note that none of the programmers
surveyed incorporated work done independently without reviewing it.

Live a balanced life
Communicating with others on a regular basis is key for leading a balanced life. “If asked, most
programmers would probably say they preferred to work alone in a place where they wouldn't be
disturbed by other people (Weinberg 1998).” But, informal discussions with other programmers
– the one you are paired with or any other – allow for effective idea exchange and efficient
transfer of information. For example, The Psychology of Computer Programming (Weinberg
1998) discusses a large university computing center. A common space with a collection of
vending machines was in the back of the room. Some serious-minded students complained about
the noise in this common space, and the vending machines were moved out. After the vending
machines were removed and signs urging quiet had been posted, a different complaint abounded
– not enough computer consultants! Suddenly, the lines for the computer consultant wound
around the room. The cause of the change: the informal chat around the vending machines had
consisted of idea exchange and information transfer between the mass of programmers. Now, all
this discussion had to be done with the relatively few consultants. (Sadly, the vending machines
were never moved back in.

When you go out into the world, watch out for traffic, hold hands and stick together.
With pair programming, the two programmers become one. There should be no competition
between the two; both must work for a singular purpose, as if the artifact was produced by a
singular good mind. Blame for problems or defects should never be placed on either partner. The
pair needs to trust each other’s judgement and each other’s loyalty to the team.

22


Be aware of the power of two brains.
Human beings can only remember and learn a bounded amount. Therefore, they must consult
with others to increase this bounded amount. When two are working together, each has their own
set of knowledge and skills. A large subset of this knowledge and these skills will be common
between the two, allowing them to interact effectively. However, the unique skills of each
individual will allow them to engage in interactions which pool their resources to accomplish
their tasks. “Collaborative people are those who identify a possibility and recognize that their
own view, perspective, or talent is not enough to make it a reality. Collaborative people see
others not as creatures who force them to compromise, but a colleagues who can help them
amplify their talents and skills (Hargrove 1998).”
Experiences show that, together, a pair will come up with more than twice as many possible
solutions than the two would have working alone. They will then proceed to more quickly
narrow in on the “best” solution and will implement it more quickly and with better quality. A
survey respondent reflects, “It is a powerful technique as there are two brains concentrating on
the same problem all the time. It forces one to concentrate fully on the problem at hand.”
Summary
Anecdotal and initial statistical evidence indicates that pair programming is a powerful technique
for productively generating high quality software products. The pair works and shares ideas
together to tackle the complexities of software development. They continuously perform
inspections on each other’s artifacts leading to the earliest, most efficient form of defect removal
possible. In addition, they keep each other intently focused on the task at hand. Programmers,
however, have generally been conditioned to performing solitary work, rooted at an educational
system of individual evaluation, perhaps, to the exclusion of learning. Making the transition to
pair programming involves breaking down some personal barriers beginning with the
understanding that talking is not cheating. First, the programmers must understand that the
benefits of intercommunication outweigh their common (perhaps innate) preference for working
alone and undisturbed. Secondly, they must confidently share their work, accepting instruction
and suggestions for improvement in order to improve their own skills and the product at hand.
They must display humility in understanding that they are not infallible and that their partner has
the ability to make improvements in what they do. Lastly, a pair programmer must accept

23


ownership of their partner’s work and, therefore, be willing to constructively express criticism
and suggested improvements. The transition to pair programming takes the conditioned solitary
programmer out of their “comfort zone.”However, the potential for achieving results impossible
by a single programmer makes this a journey to greatness.

24

Extreme programming

More Related Content

Extreme programming