BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage Pair Programming Content on InfoQ

  • How TDD and Pairing Increase Production

    "Test-driven Development" and "Pair Programming" are two of the most widely known of agile practices, yet are still largely not being practiced by many agile teams. Often, people will cite being "too busy" to adopt such practices as TDD and pairing; in essence, implying that striving for high code quality will reduce productivity. Mike Hill explains how this logic is seriously flawed.

  • Models of Apprenticeship

    Uncle Bob Martin recently wrote about his experience with apprentices and what he considers key to progressing from apprentice to journeyman. He describes two hypothetical apprentices: Sam, a developer who has apprenticed with the same master and had the same year fifteen years in a row. Jasmine has changed jobs (and therefore masters) a number of times - growing her skills along the way.

  • Article: Successfully Adopting Pair Programming

    Jay Fields presents several concrete strategies to go from "I think pair programming is a good idea" to "our team is successfully practicing pair programming and loving it!" He covers everything from pairing stations (the physical layout of your office space), to coaching tips, to common mistakes that those new to pair programming make.

  • Pair Programming vs. Code Review

    Pair programming and code review are each practices that improve the quality of software, as well as promote knowledge sharing. When the agile vs. lean, XP vs. Scrum, and vi vs. Emacs debates get slow, developers have been known to debate the merits of pair programming vs. code review. Theodore Nguyen-Cao described code reviewers as chickens, and paired programmers as pigs.

  • Burn Stories Not Tasks

    Developers commonly break user stories into tasks to facilitate distributing the implementation work across the team, and allow tracking of progress at a finer level of granularity. Unfortunately, a story can explode into a list of non-trivial tasks so large that the story is not deliverable by the end of the iteration. Ron Jeffries suggests: "Do stories as a unit, not broken into tasks."

  • Handling Your Team's "Rotten Apple"

    Recently there has been an active discussion in the Scrum Development Yahoo Group about handling an "under-performing" team member. In the 130+ response thread, "Rotten apple in Scrum team", talk ranged from advice for the primary question, to talk of team morale and who manages it, to the classic debate of measuring individuals, to distinguishing whether a team is really a "team", and more.

  • A Journeyman's Pair Programming Tour

    Corey Haines has embarked on a unique personal "Pair Programming Tour". Now three weeks into this innovative journey, Haines has posted video interviews revealing many of the unique insights he's gained about pairing, automated testing, and the evolution of a software craftsman while sharing the keyboard at the home-bases of Dave Chelimsky, Brian Marick, Uncle Bob Martin, and others.

  • Integrating Testers on to the Agile Team

    What is the role of testers on an Agile team? What is their day to day experience like? What lessons have they learned

  • Stories of Scrum Adoption in China

    This recent inquiry, by InfoQ China editor Jacky Li, looked at five very different cases of Scrum adoption in China, which got different results. He asked: Why did you use Scrum? How did you adopt it? What problems did you encounter, and why did it succeed or fail? Despite the small sample size, it's an interesting comparison, pointing out that improvement doesn't ensure success.

  • Bedtime User Stories: Cowboys and Fairytales

    In which David Longstreet claims Agile Software Development is a Fairy Tale that just tries to legitimise Cowboy development, and Geoff Slinker invites him to write a Serious Article based on Logical Arguments and Citing Sources.

  • Analyzing Experimental Data Concerning Agile Practices

    Agile literature is sprinkled with experiments on the effectiveness of one or more practices. Not all experiments come to the same conclusion. Some experiments come to conclusions that may not coincide with your team’s experience. To understand experimental results, and the level of confidence that you should have in their outcomes, an understanding of a few simple evaluation criteria is helpful.

  • Has Agile Crossed the Chasm?

    Carrying on from last year's survey, Scott Ambler published the 2007 Agile Adoption survey this month. InfoQ provides some analysis of his findings and asks readers how they would approach getting a single view of Agile trends from across the community.

  • Interview: Linda Rising on Collaboration, Bonobos and the Brain

    Seasoned practitioners packed a small room at Agile2006 to hear Linda Rising's "Are Agilists the Bonobos of the Software Community?" where she shared her thoughts on the evolutionary roots of teamwork. In this InfoQ interview, Linda talked with editor Deborah Hartmann about how writing her book "Fearless Change" led her to read on the science of the human brain and the social rituals of apes.

  • Debating the Merits of Pair Programming

    Mike Arace writes about his negative early impressions of pair programming. Are the benefits of pair programming worth the costs?

  • Sharing What's Worked: Patterns for Adopting Agile Practices

    Organizations adopting Agile naturally ask these questions; "Where do I start?", "What specific practices should I adopt?", "How can I adopt incrementally?" and "Where can I expect pitfalls?" In this article, Amr Elssamadisy gives a glimpse into an ongoing effort to document Agile practice adoption patterns: Participants at XPday Montreal took a stab at "Simple Design" and "Pair Programming."

BT