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

  • XP or Scrum, Either, Both, or Neither?

    Which is better? Scrum or XP? Is there one that is more applicable than the other or is there another alternative?

  • Opinion: Pair Programming Is Not For The Masses

    Pair Programming continues to be one of the most debated and controversial practices of recent years. Most proponents don't falter in their praise of the benefits, but many of even these same people will admit they struggle to get pairing really going in their shops. Why? Obie Fernandez opinions 10 reasons why this might be so.

  • PairWithUs: On-Demand Agile Software Development Video Examples

    One thing well known by most programmers is that the best (only?) way to learn programming technique is by example; specifically, watching someone else doing it. Antony Marcano & Andy Palmer's 'PairWithUs' gives people a great place to do just that.

  • How to Transfer Knowledge in an Agile Project

    Knowledge transfer is characterized by transfer of understanding, about a context, from one unit (individual, team, department, organization) to another. In a series of interesting experiments, Steve Bockman tried to figure out the best way to transfer knowledge in an Agile project.

  • A Dollar Value On Pair Programming

    "Why in the world would we use two people to do the job of one?" This is often the initial reaction to people when first introduced to the idea of pair programming. In essence, they perceive pair programming as doubling the cost of writing any segment of code. Dave Nicollete offers some quantitive ideas to help show how pair programming can save money, not waste it.

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

  • A Good Velocity

    Buddha Buck recently asked the Extreme Programming list if there were a velocity range that could be considered 'good' for a team of about seven people doing two-week iterations. He felt that a velocity of eight or below indicated that the team's stories might be too big. The resulting discussion provided some answers to the question, and the questions behind the question.

  • Presentation: A Tale of 2 Systems

    In this video recorded during QCon London 2008, Pete Goodliffe presents two Linux-based audio products with a complete different outcome, software design making the difference.

  • Presentation: 10 Ways to Improve Your Code

    In this presentation recorded during QCon SF 2008, Neal Ford, an architect at ThoughtWorks, shows 10 ways to write better code. This is practical advice for developers, but application architects can benefit from it too.

  • An Agile Approach to Code Reuse

    A recent discussion on the Extreme Programming Yahoo Group explored the apparent conflict between making software reusable and the XP practice of not writing code until it is needed. Ron Jeffries and others shared insights about the costs and benefits of code reuse, as well as how and when to do it in an agile environment.

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

  • Adopting The Whole Enchilada

    Recently InfoQ reported on Jim Shore's 'The Decline and Fall of Agile', which highlighted a trend for organizations to adopt "Agile" (in name) but fail to adopt what it means to be Agile (in practice). Community leaders such as Joshua Kerievsky, Martin Fowler, and Ron Jeffries have taken Shore's post a few steps further recently, posting their own thoughts on what's going on with this situation.

  • Interview: Similarities Between Interaction Designers and Agile Programmers

    In this interview taken during Agile 2008, Alan Cooper, the father of Visual Basic and supporter of interaction design, talks about his contact with the Agile movement and the similarities discovered between Agile programmers and interaction designers.

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

BT