DZone
Agile Zone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
  • Refcardz
  • Trend Reports
  • Webinars
  • Zones
  • |
    • Agile
    • AI
    • Big Data
    • Cloud
    • Database
    • DevOps
    • Integration
    • IoT
    • Java
    • Microservices
    • Open Source
    • Performance
    • Security
    • Web Dev
DZone > Agile Zone > Buddy Programming

Buddy Programming

When I encounter a team that’s reluctant to try pairing, sometimes I’ll suggest another technique that I call buddy programming.

David Bernstein user avatar by
David Bernstein
CORE ·
Jan. 23, 17 · Agile Zone · Opinion
Like (2)
Save
Tweet
5.06K Views

Join the DZone community and get the full member experience.

Join For Free

Sometimes, the practices of Extreme Programming can be a bit too extreme when first introducing them to a team. This is especially true with pair programming.

Of all the practices that I teach software developers, I get the most resistance from pair programming, Both developers and their managers are skeptical about pair programming, although each has different concerns.

Managers tell me they can’t afford to cut their developers’ productivity in half — but that actually doesn’t happen. Productivity increases for teams that do pair programming well for a number of reasons, but most fundamentally because when people are working together, they stay focused on a task more consistently than when they’re working on their own. This has several side effects, including fewer bugs, higher quality code, and better work habits.

The resistance I get from developers is different. Their main concern is often compatibility between partners, but it usually turns out that we can be most productive with people who are different from us rather than the same as us. It’s the differences between us that make for a good pair. Our differences can often complement each other. When everybody understands the ground rules and the purpose of pairing, it can grow into a very positive experience.

I know teams who pair on everything because they find so much value in it most of the time. Of the hundreds of teams I’ve introduced pair programming to, many of them continue to use the practices. Developers love pair programming when they’re introduced to it correctly.

The trick to getting a team to adapt pair programming is often just getting them to try it. When I encounter a team that’s reluctant to try pairing, sometimes I’ll suggest another technique that I call buddy programming.

Buddy programming is not pair programming. With buddy programming you work on your own, by yourself, for most of the day, the way traditional knowledge workers typically work. However, at the end of the day, you get together with your buddy and walk through the code you each wrote since the last time you were together.

You’re checking in with another person, either at the end of the day or at the beginning of the next day for maybe an hour or so and reviewing each other’s work including decisions, designs, code, questions, etc. I find that this approach can often be a gateway for developers to adopt pair programming. They find it so productive working with their buddy that they do more and more of it throughout the day until it eventually goes from code reviews to code creation.

Some teams prefer to stay with buddy programming and use it as a way of enforcing code reviews among the team. However, I have seen other teams soften to the notion of pairing and move from buddy programming to pair programming as the way they work most of the time.

teams

Published at DZone with permission of David Bernstein, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

Popular on DZone

  • How to Classify NSFW (Not Safe for Work) Imagery with AI Content Moderation using Java
  • MEAN vs MERN Stack: Which One Is Better?
  • How to Solve Context Propagation Challenges in Distributed Tracing
  • The Importance of Semantics for Data Lakehouses

Comments

Agile Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • MVB Program
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com
  • +1 (919) 678-0300

Let's be friends:

DZone.com is powered by 

AnswerHub logo