Extreme programming

14,286 views
13,954 views

Published on

Published in: Technology
3 Comments
5 Likes
Statistics
Notes
No Downloads
Views
Total views
14,286
On SlideShare
0
From Embeds
0
Number of Embeds
16
Actions
Shares
0
Downloads
473
Comments
3
Likes
5
Embeds 0
No embeds

No notes for slide

Extreme programming

  1. 1. Extreme & Pair ProgrammingExtreme ProgrammingWhat is Extreme Programming? (XP)Extreme Programming (XP) is a software engineering methodology, the most prominent ofseveral agile software development methodologies. Like other agile methodologies, ExtremeProgramming differs from traditional methodologies primarily in placing a higher value onadaptability than on predictability. Proponents of XP regard ongoing changes to requirements asan often natural and often inescapable aspect of software development projects; they believe thatbeing able to adapt to changing requirements at any point during the project life is a morerealistic and better approach than attempting to define all requirements at the beginning of aproject and then expending effort to control changes to the requirements. XP prescribes a set ofday-to-day practices for managers and developers; the practices are meant to embody andencourage particular values. Proponents believe that the exercise of these practices—which aretraditional software engineering practices taken to so-called "extreme" levels—leads to adevelopment process that is more responsive to customer needs ("agile") than traditionalmethods, while creating software of similar or better quality.OriginsSoftware development in the 1990s was shaped by two major influences: internally, object-oriented programming replaced procedural programming as the programming paradigm favoredby some in the industry. Rapidly-changing requirements demanded shorter product life-cycles,and were often incompatible with traditional methods of software development.Variouscontributors 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 stateXP created quite a buzz in the late 1990s and early 2000s, seeing adoption in a number ofenvironments radically different from its origins. The high discipline required by the original 1
  2. 2. Extreme & Pair Programmingpractices often went by the wayside, causing certain practices to be deprecated or left undone onindividual sites. Agile development practices have not stood still, and XP is still evolving,assimilating more lessons from experiences in the field.Goal of Extreme ProgrammingExtreme Programming is described as being: • An attempt to reconcile humanity and productivity • A mechanism for social change • A path to improvement • A style of developmentThe 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 thedevelopment project and often fixed from that point on. This means that the cost of changing therequirements at a later stage will be high. XP sets out to lower the cost of change by introducingbasic values, principles and practices. By applying XP, a system development project should bemore flexible with respect to changes.Extreme Programming valuesExtreme Programming initially recognized four values. A new value was added in the secondedition of Extreme Programming Explained. The five values are:• Communication• Simplicity• Feedback• Courage• RespectBuilding software systems requires communicating system requirements to the developers of thesystem. In formal software development methodologies, this task is accomplished throughdocumentation. Extreme Programming techniques can be viewed as methods for rapidly buildingand disseminating institutional knowledge among members of a development team. The goal isto give all developers a shared view of the system which matches the view held by the users ofthe system. To this end, Extreme Programming favors simple designs, common metaphors, 2
  3. 3. Extreme & Pair Programmingcollaboration of users and programmers, frequent verbal communication, and feedback.Extreme Programming encourages starting with the simplest solution and refactoring to betterones. The difference between this approach and more conventional system development methodsis the focus on designing and coding for the needs of today instead of those of tomorrow, nextweek, or next month. Proponents of XP acknowledge the disadvantage that this can sometimesentail more effort tomorrow to change the system; their claim is that this is more thancompensated for by the advantage of not investing in possible future requirements that mightchange before they become relevant. Coding and designing for uncertain future requirementsimplies 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 mostprogrammers in the team.Within Extreme Programming, feedback relates to different dimensions of the systemdevelopment:Feedback from the systemby writing unit tests, or running periodic integration tests, the programmers have directfeedback from the state of the system after implementing changes.Feedback from the customerThe functional tests (aka acceptance tests) are written by the customer and the testers. Theywill get concrete feedback about the current state of their system. This review is plannedonce in every two or three weeks so the customer can easily steer the development.Feedback from the teamWhen customers come up with new requirements in the planning game the team directlygives an estimation of the time that it will take to implement.Feedback is closely related to communication and simplicity. Flaws in the system are easilycommunicated by writing a unit test that proves a certain piece of code will break. The direct 3
  4. 4. Extreme & Pair Programmingfeedback from the system tells programmers to recode this part. A customer is able to test thesystem periodically according to the functional requirements (aka user stories). To quote KentBeck, "Optimism is an occupational hazard of programming, feedback is the treatment."Several practices embody courage. One is the commandment to always design and code fortoday and not for tomorrow. This is an effort to avoid getting bogged down in design andrequiring a lot of effort to implement anything else. Courage enables developers to feelcomfortable with refactoring their code when necessary. This means reviewing the existingsystem and modifying it so that future changes can be implemented more easily. Anotherexample of courage is knowing when to throw code away: courage to remove source code that isobsolete, no matter how much effort was used to create that source code. Also, courage meanspersistence: A programmer might be stuck on a complex problem for an entire day, then solvethe problem quickly the next day, if only he or she is persistent.The respect value manifests in several ways. In Extreme Programming, team members respecteach other because programmers should never commit changes that break compilation, that makeexisting unit-tests fail, or that otherwise delay the work of their peers. Members respect theirwork by always striving for high quality and seeking for the best design for the solution at handthrough refactoring.Principle Of Extreme ProgrammingThe principles that form the basis of XP are based on the values just described and are intendedto foster decisions in a system development project. The principles are intended to be moreconcrete 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 iscritical to learning and making changes. In Extreme Programming, unlike traditional systemdevelopment methods, contact with the customer occurs in small iterations. The customer hasclear insight into the system that is being developed. He or she can give feedback and steer thedevelopment as needed.Unit tests also contribute to the rapid feedback principle. When writing code, the unit testprovides direct feedback as to how the system reacts to the changes one has made. If, for 4
  5. 5. Extreme & Pair Programminginstance, the changes affect a part of the system that is not in the scope of the programmer whomade them, that programmer will not notice the flaw. There is a large chance that this bug willappear when the system is in production.Simplicity is about treating every problem as if its solution were extremely simple. Traditionalsystem development methods say to plan for the future and to code for reusability. Extremeprogramming 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 smallreleases every three weeks. By making many little steps the customer has more control over thedevelopment 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 customers requirements havechanged dramatically, programmers are to embrace this and plan the new requirements for thenext iteration.Extreme Programming Life CycleExtreme Programming is an agile method of software development focused on providing thehighest value for the customer in the fastest way possible. Read on for an understanding of theextreme programming life cycle and how it can benefit you. The traditional softwaredevelopment process is linear, with each stage of the lifecycle requiring completion of theprevious stage. For instance, design starts only on completion of the entire analysis of theprogram, and coding starts only after completion and freezing of the design. This concept workswell when customer requirements remain static, but in practice, requirements change frequentlyand cause frequent editing of programs leading to errors and software ‘rot.’Extreme Programming (XP) turns the traditional software development process sideways. Ratherthan planning, analyzing, and designing in a linear fashion, XP programmers do all suchactivities a little at a time throughout the development phase. The approach bears resemblance toa jigsaw puzzle with the development of many small pieces or iterations that make no sense 5
  6. 6. Extreme & Pair Programmingindividually, but making for a complete package when combined. The biggest advantage of thisapproach is the resilience it provides, allowing for easy incorporation of changes.The Extreme Programming software development process starts with planning, and all iterationsconsist of four basic phases in its life cycle: designing, coding, testing, and listening. Theoverriding values that drives the XP life cycle are continual communication with the customerand amongst the team, simplicity by harping on the minimalist solution, frequent feedbackthrough unit and acceptance testing, and the courage to take on problems proactively andintegrate testing and changes in the development phase.PlanningThe first phase of Extreme Programming life cycle is planning, where customers or users meetwith the development team to create ‘user stories’ or requirements. The development teamconverts user stories into iterations that cover a small part of the functionality or featuresrequired. A combination of iterations provides the customer with the final fully functionalproduct. 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 pathmethod, grouping iterations essential for project progress in a linear fashion, and arranging forcompletion of other iterations parallel to the critical path.DesigningAn 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
  7. 7. Extreme & Pair Programminganticipation. Using systems metaphor or standards on names, class names and methods, andagreeing on uniform styles and formats to ensure compatibility among the work of differentteam members. Using Software Class Responsibilities and Collaboration (CRC) Cards thatallow for a departure from the traditional procedural mindset and make possible object orientedtechnology. Such cards allow all members of the project team to contribute ideas, and collatethe best ideas into the design. Creating spike solutions or simple programs that explorepotential solutions for a specific problem, ignoring all other concerns, to mitigate risk.CodingCoding constitutes the most important phase in the Extreme Programming life cycle. XPprogramming gives priority to the actual coding over all other tasks such as documentation toensure 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 ofcollective code ownership. Pair programming or developing code by two programmers workingtogether 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 inthe peak of their mental and physical faculties. Frequent integration of the code to the dedicatedrepository, with only one pair integrating at a time to prevent conflicts, and optimization at theend.TestingExtreme program integrates testing with the development phase rather than at the end of thedevelopment phase. All codes have unit tests to eliminate bugs, and the code passes all such unittests before release. Another key test is customer acceptance tests, based on the customerspecifications. Acceptance test run at the completion of the coding, and the developers providethe customer with the results of the acceptance tests along with demonstrations. 7
  8. 8. Extreme & Pair ProgrammingListeningThe basis of extreme programming is a continuous mechanism of customer involvement throughfeedback during the development phase. Apart from the customer, the developer also receivesfeedback from the project manager.The basis of feedback is the customer acceptance tests. Eachfeedback 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 satisfiedwith the test results the iteration ends there, and the design for the new iteration starts, whichagain follows the design-coding-testing-listening cycle.Extreme Programming PracticesExtreme Programming has 12 practices, grouped into four areas, derived from the best practicesof 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
  9. 9. Extreme & Pair Programming 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 iterationExtreme 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
  10. 10. Extreme & Pair Programming• System always improves, never backslidesExtreme 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 teamExtreme 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
  11. 11. Extreme & Pair ProgrammingExtreme 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 testsExtreme 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 freezesExtreme 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 codeExtreme 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 ownershipExtreme Programming Practices: Metaphor• XP Teams develop a common vision of the system 11
  12. 12. Extreme & Pair Programming• 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 functionalityExtreme 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 CourageXP 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
  13. 13. Extreme & Pair Programming 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 succeedExtreme Programming Criticism • Unrealistic--programmer centric, not business focused • Detailed specifications are not written • Design after testing • Constant refactoring • Customer availability • 12 practices are too interdependentApplication of Extreme ProgrammingExtreme Programming remains a sensible choice for some projects. Projects suited to ExtremeProgramming are those that:Involve new or prototype technology, where the requirements change rapidly, or somedevelopment is required to discover unforeseen implementation problemsAre research projects, where the resulting work is not the software product itself, but domainknowledge 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 willoccur Involve mission critical or safety critical systems, where formal methods must be 13
  14. 14. Extreme & Pair Programmingemployed for safety or insurance reasons Are large projects which may overwhelm informalcommunication mechanisms Have complex products which continue beyond the project scope torequire frequent and significant alterations, where a recorded knowledge base, or documentationset, becomes a fundamental necessity to support the maintenanceProject Managers must weigh project aspects against available methodologies to make anappropriate selection.ConclusionHigh ceremony’ software engineering methodologies in disfavor Agile software developmentmethodologies in increasing use, but with significant criticism Formal methods will never have asignificant impact until they can be used by people that don’t understand them. 14
  15. 15. Extreme & Pair ProgrammingPair ProgrammingPair programming has become popular word among software developers recently. As the namesuggests, pair programming is a software development activity (writing code) which is done bytwo programmers. There will be only one of them writes the code and the other programmerthinks whether the code written satisfy their goals. The idea is similar with rallying where in onecar there are two people. They are the driver and co-driver. The driver will drive the car and theco-driver will guide the driver to drive accurately.Pair programming is a programming technique adopted by extreme programming or any agilesoftware development methodologies. Some people argue that this method is a good practice. Onthe other hand, there are many people say that it is sorrowful. In this blog, the benefits anddrawbacks of pair programming will be analyzed, to understand whether pair programming ispainful or not.Some benefits of pair programming are efficiency and increase in performance. In term ofefficiency, we can cut the number of workstations as well as software licenses since we needonly one workstation every two developers. However, the main advantage that people lookingfor in this programming approach is an improvement in developer performance. This includes anincrease on the number of line of codes and reduced number of bugs or defects in the writtencode. This can be achieved, because one of the programmers can concentrate to write the codeand another one analyzes the code which is written on the screen. If there is something wrongwith 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 areworking. That is why we can find cubicles in many working places. Some people find that it ishard to work under tight supervision. The other problem is every human has their own style andway of thinking. This is also applied in coding style and logical flow within our source code. Inmy opinion, it is difficult to understand other programmer’s code or adopt their styles, especiallyif there is a big different in the experience and programming skills. 15
  16. 16. Extreme & Pair ProgrammingAll of the drawbacks of pair programming are most likely caused by unmatched programmerbeing paired. I believe this can be solved if both programmer can get a long together and havethe same level of programming skills. It will be better if both programmers come from the sameprogramming language background since there is a big probability they will have sameprogramming styles. It is not an easy task to pair up developers in a project.IntroductionPair programming is a style of programming in which two programmers work side-by-side at onecomputer, continuously collaborating on the same design, algorithm, code or test. As discussedbelow, use of this practice has been demonstrated to improve productivity and quality ofsoftware products. Additionally, based on a survey (Williams 1999) of pair programmers(hereafter referred to as “the pair programming survey"), 100% agreed that they had moreconfidence 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 resistthe transition to pair programming. Ultimately, most triumphantly make this transition. Thispurpose of this paper is to aid programmers in becoming effective pair programmers. Thetransition 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 withpoetic license) will be explored for the inherent lessons related to successful pair programming.Pair Programming: Evidence of SuccessAnecdotal and initial statistical evidence indicates pair programming is highly beneficial.Extreme Programming (XP), an emerging software development methodology, attributes greatsuccess to the use of “pair programming.” XP was developed initially by Smalltalk codedeveloper and consultant Kent Beck with colleagues Ward Cunningham and Ron Jeffries. Theevidence of XP’s success is highly anecdotal, but so impressive that it has aroused the curiosityof many highly-respected software engineering researchers and consultants. The largest exampleof its accomplishment is the sizable Chrysler Comprehensive Compensation system launched inMay 1997. After finding significant, initial development problems, Beck and Jeffries restarted 16
  17. 17. Extreme & Pair Programmingthis development using XP principles. The payroll system pays some 10,000 monthly-paidemployees and has 2,000 classes and 30,000 methods, (Anderson 1998), went into productionalmost on schedule, and is still operational today. Additionally, programmers at Ford MotorCompany, spent four unsuccessful years trying to build the Vehicle Cost and Profit System(VCAPS) using a traditional waterfall methodology. The XP developers successfullyimplemented 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 witha partner. XP advocates pair programming with such fervor that even prototyping done solo isscrapped and re-written with a partner. One key element is that while working in pairs acontinuous code review is performed, noting that it is amazing how many obvious but unnoticeddefects 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 morethan twice as many solutions to a problem as two working alone, while attaining higher defectprevention and defect removal leading to a higher quality product. Two other studies support theuse of pair programming. Larry Constantine, a programmer, consultant, and magazine columnistreports on observing “Dynamic Duos” during a visit to P. J. Plaugher’s softwarecompany, Whitesmiths, Ltd, providing anecdotal support for collaborative programming. Heimmediately noticed that at each terminal were two programmers working on the same code. Hereports, “Having adopted this approach, they were delivering finished and tested code faster thanever . . . The code that came out the back of the two programmer terminals was nearly 100% bugfree . . . it was better code,tighter and more efficient, having benefited from the thinking of twobright minds and the steady dialogue between two trusted terminal-mates . . . Two programmersin tandem is not redundancy; it’s a direct route to greater efficiency and betterquality.”(Constantine 1995)An experiment by Temple University Professor Nosek studied 15 full-time, experiencedprogrammers 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 workedcollaboratively in five pairs. Conditions and materials used were the same for both theexperimental (team) and control (individual) groups. This study provided statistically significantresults, using a two-sided t-test. “To the surprise of the managers and participants, all the teamsoutperformed the individual programmers, enjoyed the problem-solving process more, and had 17
  18. 18. Extreme & Pair Programminggreater confidence in their solutions.” The groups completed the task 40% more quickly andeffectively by producing better algorithms and code in less time. The majority of theprogrammers were skeptical of the value of collaboration in working on the same problem andthought it would not be an enjoyable process. However, results show collaboration improvedboth 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 onlycode we have ever had errors in was code that wasn’t pair programmed . . . we should reallyquestion a situation where it isn’t utilized.” Given these successes, lets review some principlesof 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 workingwith one mind, responsible for every aspect of this artifact. One person is typing or writing, theother is continually reviewing the work. But, both are equal participants in the process. It is notacceptable to say or think things such as, “You made an error in your design.” or “That defectwas from your part.” Instead, “We screwed up the design.” or, better yet, “We just got throughtest with no defects!” Both partners own everything.Play fair.With pair programming, one person “drives” (has control of the keyboard or is recording designideas) while the other is continuously reviewing the work. Even when one programmer issignificantly more experienced than the other, it is important to take turns “driving,” lest theobserver become disjoint, feel out of the loop or unimportant. The person not driving is not apassive observer, instead is always active and engaged. “Just watching someone program isabout as interesting as watching grass die in a desert (Beck to be published).” In the pairprogramming survey, approximately 90% stated that the main role of the person not typing wasto perform continuous analysis, design and code reviews. “When one partner is busy typing, theother is thinking at a more strategic level – where is this line of development going? Will it runinto a dead end? Is there a better overall strategy? 18
  19. 19. Extreme & Pair ProgrammingDon’t hit your partner.But, make sure your partner stays focused and on-task. Doubtlessly, a benefit of working in pairsis that each is far less likely to “waste time” reading e-mail, surfing the web, or zoning out thewindow – because their partner is awaiting continuous contribution and input. Additionally, eachis expecting the other to follow the prescribed development practices. “With your partnerwatching, though, chances are that even if you feel like blowing off one of these practices, yourpartner won’t . . . the chances of ignoring your commitment to the rest of the team is muchsmaller 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 bythe other person all the time; neither person feels they can slack off.” As each keeps their partnerfocused 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 atruth. If you tell yourself something negative, such as “I’m a terrible programmer,” soon yourbrain will believe you. However, anyone can control this negative self-talk by putting thesethoughts where they belong, in the trash can, every time they start to creep into their brain. Thesurveyed pair programmers indicated that it was very difficult to work with someone who had agreat 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. Programmerswith such insecurity should view pair programming as a means to improve their skill byconstantly watching and obtaining feedback from another. A survey respondent reflected, “Thebest thing about pair programming for me is the continuous discussion gave me training informulating the thoughts I have about design and programming, thereby helping me reflect overthem, which has made me a better designer/programmer.” Indeed, two researchers surveyed 750working programmers on coordination techniques in software development. The communicationtechnique with both the highest use and the highest value was “discussion with peers.” “Thestandard response when one confronts a problem that cannot be solved alone is to go to acolleague close by (Kraut 1995).” When pair programming, the “colleague close by” iscontinuously available. Together the pair can solve problems they couldn’t solve alone and canhelp improve each other’s skills. Also, negative thoughts such as “I’m an awesome programmer, 19
  20. 20. Extreme & Pair Programmingand I’m paired up with a total loser” should also find their place in the trash can, lest thecollaborative relationship be destroyed. None of us, no matter how skilled, is infallible and abovethe input of another. John von Neumann, the great mathematician and creator of the vonNeumann computer architecture, recognized his own inadequacies and continuously asked othersto review his work. “And indeed, there can be no doubt of von Neumanns genius. His veryability to realize his human limitation put him head and shoulders above the average programmertoday . . . Average people can be trained to accept their humanity -- their inability to functionlike a machine -- and to value it and work with others so as to keep it under the kind of controlneeded 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 becomenoticed by another person watching over your shoulder. Additionally, these defects can beremoved without the natural animosity that might develop in a formal inspection meeting.Established software engineering techniques often stress the importance of defect prevention andefficient defect removal. This “watch over the shoulder” technique, perhaps, epitomizes defectprevention and defect removal efficiency.Don’t take things too seriously.“Ego-less programming,” an idea surfaced by Gerald Weinberg in The Psychology of ComputerProgramming (recently re-reported in Weinberg 1998) a quarter of a century ago, is essential foreffective pair programming. According to the pair programming survey, excess ego can manifestitself in two ways, both damaging the collaborative relationship. First, having a “my way or thehighway” attitude can prevent the programmer from considering others ideas. Secondly, excessego can cause a programmer to be defensive when receiving criticism or to view this criticism asmistrust. In The Psychology of Computer Programming (Weinberg 1998), a true scenario about aprogrammer seeking review of the code he produced is discussed. On this particular “badprogramming” day, this individual laughed at himself because his reviewer found seventeen bugsin thirteen statements. However, after fixing these defects, this code performed flawlessly duringtest and in production. How different this outcome might have been had this programmer beentoo proud to accept the input of others or had viewed this input as an indication of his 20
  21. 21. Extreme & Pair Programminginadequacies. Having another to continuously and objectively review design and coding is a verybeneficial aspect of pair programming. “The human eye has an almost infinite capacity for notseeing what it does not want to see . . . Programmers, if left to their own devices, will ignore themost glaring errors in their output -- errors that anyone else can see in an instant (Weinberg1998)."Conversely, a person who always agrees with their partner lest create tension alsominimizes the benefits of collaborative work. For favorable idea exchange, there should be somehealthy disagreement/debate. Notably, there is a fine balance between displaying too much andtoo 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 thisinitial adjustment period can take hours or days, depending on the individuals, nature of workand 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 workspacelayout was critical to their success. The programmers must be able to sit side-by-side andprogram, simultaneously viewing the computer screen and sharing the keyboard and mouse. Inthe diagram below (from (Beck 1999)), layouts to the right are preferable to layouts on the left.Extreme programmers have a “slide the keyboard/dont move the chairs” rule. Effectivecommunication, 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 makedecisions 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 canhave vital contributions. Separate offices and cubicles can inhibit this necessary exchange. "Ifany one thing proves that psychological research has been ignored by working managers, its thecontinuing use of half partitions to divide workspace into cubicles. … Like many kings, somemanagers use divide-and-conquer tactics to rule their subjects, but programmers need contactwith other programmers. (Weinberg 1998)”Pair programmers take aggressive action on improving their physical environment, by takingmatters into their own hands (armed with screwdrivers).Inevitably, the pair programmers will work on something independently. Of the programmersthat were surveyed, over half said that when they rejoined with their partner, they reviewed this 21
  22. 22. Extreme & Pair Programmingindependent work and then incorporated it into the project. Alternately, Extreme Programmersflush and rewrite independent work. In their XP experience, the majority of the defects theyfound could be traced back to a time when a programmer worked independently. In fact, in theirChrysler Comprehensive Compensation project during the last five months before firstproduction, the only defects that made it through unit and functional testing were written bysomeone programming alone. In re-writing, the author must undergo the customary continuousreview of the work, which identifies additional defects. The decision to flush or to review workdone independently can be made by a pair of programmers, or the choice may be encouraged, asit is with Extreme Programming. However, it is important to note that none of the programmerssurveyed incorporated work done independently without reviewing it.Live a balanced lifeCommunicating with others on a regular basis is key for leading a balanced life. “If asked, mostprogrammers would probably say they preferred to work alone in a place where they wouldnt bedisturbed 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 efficienttransfer of information. For example, The Psychology of Computer Programming (Weinberg1998) discusses a large university computing center. A common space with a collection ofvending machines was in the back of the room. Some serious-minded students complained aboutthe noise in this common space, and the vending machines were moved out. After the vendingmachines were removed and signs urging quiet had been posted, a different complaint abounded– not enough computer consultants! Suddenly, the lines for the computer consultant woundaround the room. The cause of the change: the informal chat around the vending machines hadconsisted of idea exchange and information transfer between the mass of programmers. Now, allthis discussion had to be done with the relatively few consultants. (Sadly, the vending machineswere 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 competitionbetween the two; both must work for a singular purpose, as if the artifact was produced by asingular good mind. Blame for problems or defects should never be placed on either partner. Thepair needs to trust each other’s judgement and each other’s loyalty to the team. 22
  23. 23. Extreme & Pair ProgrammingBe aware of the power of two brains.Human beings can only remember and learn a bounded amount. Therefore, they must consultwith others to increase this bounded amount. When two are working together, each has their ownset of knowledge and skills. A large subset of this knowledge and these skills will be commonbetween the two, allowing them to interact effectively. However, the unique skills of eachindividual will allow them to engage in interactions which pool their resources to accomplishtheir tasks. “Collaborative people are those who identify a possibility and recognize that theirown view, perspective, or talent is not enough to make it a reality. Collaborative people seeothers not as creatures who force them to compromise, but a colleagues who can help themamplify their talents and skills (Hargrove 1998).”Experiences show that, together, a pair will come up with more than twice as many possiblesolutions than the two would have working alone. They will then proceed to more quicklynarrow in on the “best” solution and will implement it more quickly and with better quality. Asurvey respondent reflects, “It is a powerful technique as there are two brains concentrating onthe same problem all the time. It forces one to concentrate fully on the problem at hand.”SummaryAnecdotal and initial statistical evidence indicates that pair programming is a powerful techniquefor productively generating high quality software products. The pair works and shares ideastogether to tackle the complexities of software development. They continuously performinspections on each other’s artifacts leading to the earliest, most efficient form of defect removalpossible. 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 educationalsystem of individual evaluation, perhaps, to the exclusion of learning. Making the transition topair programming involves breaking down some personal barriers beginning with theunderstanding that talking is not cheating. First, the programmers must understand that thebenefits of intercommunication outweigh their common (perhaps innate) preference for workingalone and undisturbed. Secondly, they must confidently share their work, accepting instructionand 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 hasthe ability to make improvements in what they do. Lastly, a pair programmer must accept 23
  24. 24. Extreme & Pair Programmingownership of their partner’s work and, therefore, be willing to constructively express criticismand suggested improvements. The transition to pair programming takes the conditioned solitaryprogrammer out of their “comfort zone.”However, the potential for achieving results impossibleby a single programmer makes this a journey to greatness. 24

×