extreme programming

Extreme & Pair Programming

1

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


2

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,


3

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


4

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


5

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


6

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


7

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.


8

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.


9

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


10

• 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


11

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


12

• 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.


13

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


14

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.


15

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.


16

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


17

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


18

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?


19

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,


20

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


21

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


22

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.


23

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


24

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.

extreme programming

Technology