A reader asks for advice as his team gets started with pair programming.

Pairing can be fun, cost-effective, and risk-reductive. These benefits come with skilled practice. The needed skills can, of course, be learned. Here are my suggestions for a team new to pair programming.

1. Conserve energy

Programming solo is tiring in familiar ways. Programming in pairs is tiring in unfamiliar ways. When starting out, limit your pairing to 2 hours a day, perhaps as two separate 1-hour sessions. Later, when everyone’s gotten the hang of it and is excited about doing more, that’s the time to try doing a little more.

2. Keep participation voluntary

Collaborative work without eager, willing participation is not collaborative work at all. Anyone who doesn’t want to try pairing should not try pairing. Maybe, if everyone else seems to be having fun, they’ll change their mind; maybe not. No idea is so good that it must be forced on people.

3. Learn out loud

There are many different techniques for pairing. In “strong-style” pairing, the navigator expresses intentions and the driver listens and transcribes. Switch roles every 5 minutes. When your timer goes off, don’t worry about finishing the sentence or the thought. Just switch roles, see how well you adjust, and consider how to make the next switch easier. Worst case, you can finish the hanging thought 5 minutes from now.

4. Build pairing skill

If you’re about to try pairing, it’s probably not the only thing you’re hoping your team will try. Defer as many of those other ideas as you possibly can. Concentrate first on adjusting and getting good at working together in this new way while continuing to create code that isn’t too much different (maybe slightly better, since code review is happening all the time). When pairing is going well, it will provide a platform to disseminate new ideas. Before it’s going well, hold off on other new ideas as best you can.

5. Learn incrementally

Once you’re pairing, you’ll encounter lots of other ideas, such as writing tests first, refactoring opportunistically, and synthesizing these into Test-Driven Development.

WIP (Work-In-Progress) limits are every bit as useful for learning as they are for delivery, and for the same reasons.

Since delivery requires learning, a Learning-In-Progress limit of 1 might be too low. Try a limit of 2. For the rest, keep a shared list of everything your team would like to try. When you encounter a new something you’d like to try, add it to the list. When you’re ready to try a new something, look at the list and see what jumps out at you. Wait until you’re comfortable with what you’ve learned (enough to call it “done”) before pulling your next learning item.

6. Maybe don’t bother with pairing

Extreme Programming took a bunch of practices that had worked well and turned the dials all the way up. If we were adjusting those dials today, we’d turn the collaboration dial past pairing and work, as a whole team, on one problem at a time.

7. Invite an experienced facilitator

These guidelines may help your team navigate the shift to working together more closely. I hope they do. I hope you also consider bringing a seasoned software development coach to join you as you begin this journey. It doesn’t have to be me. :-)

Suggestions from others

Additional references

Posted Mon Dec 2 06:12:14 2019 Tags:

Manny leading a discussion

On Saturday, November 16, I was going to have once again co-facilitated the New York City instance of Global Day of Coderetreat. I wound up not doing much of that, because Emmanuel Genard from Stride Consulting had it well in hand and because the situation at home required all available parents. (Taavi, having progressed from crib to anarchy while I’d been off at a client, has since progressed to getting the hang of a new bedtime routine. Phew.) My chief contributions in a mere 90 minutes at the App Academy office in Midtown:

  1. Talked to GDCR participants in Nuremberg, where I’d made some friends on my Coding Tour last summer
  2. Talked to Edinburgh (same)
  3. Failed to talk to Montreal due to technical difficulties
  4. Distracted Manny and at least some of the participants
  5. Took a picture of them

I know, I’m impressed too.

But seriously, thank you to my friends at Stride for organizing, sponsoring, and facilitating, and to App Academy for sharing their space with us.

If you’re energized by coming home from Global Day of Coderetreat with several new points of view on a seemingly small problem, you might be the kind of person who’d enjoy a Coding Tour. I’d be more than happy to chat about what it’s like to go on tour and how you can make it happen for yourself.


Could this format for learning help your team? Code Retreat (or Legacy Code Retreat) is one of the ways your organization can benefit from my rare combination of technical coaching and impactful conversations. (Take other people’s word for it, not mine.) It’s not too late to book me for 2020. Let’s talk about what fits for you.

If that’s not your decision to make, could you personally benefit from an individualized session with an experienced, inquisitive, and empathetic conversation partner? Maybe you’re facing a challenging situation at work, a learning opportunity in some code — or both. Get in touch: latentagility.com

Posted Tue Nov 19 15:47:05 2019 Tags:

Running my own email server has its challenges. Chief among them: my favorite mail-server software hasn’t been updated since I started using it in 1998.

The qmail logo
qmail logo

Okay, that’s not entirely true. While qmail hasn’t been updated by its original author, a group of respected users created netqmail, a series of tiny updates that were informed, conservative, and careful. By their design, it was safe for everyone running qmail to follow netqmail, so everyone did. But larger changes in the world of email — authentication, encryption, and ever-shifting anti-spam techniques — remained as puzzles for each qmail administrator to solve in their own way. And netqmail hasn’t been updated since 2007.

One fork per person

In the interim, devotees have continued maintaining their own individual qmail forks. Some have shared theirs publicly. I’ve preferred the design constraints of making minimal, purpose-specific, and conflict-avoidant add-ons and patches. Then again, these choices are motivated by the needs of my qmail packaging, which I suppose is itself a de facto fork.

I’ve found this solo work quite satisfying. I’ve learned more C, reduced build-time complexity, added run-time configurability, and published unusually polished and featureful qmail packages for over 20 platforms. Based on these experiences, I’ve given dozens of workshops and talks. In seeking to simplify system administration for myself and others, I’ve become a better programmer and consultant.

Still, wouldn’t it be more satisfying if we could somehow pool our efforts? If, long after the end of DJB’s brilliant one-man show, a handful of us could shift how we relate to this codebase — and to each other — in order to bring a collaborative open-source effort to life? If, with netqmail as inspiration, we could produce safe updates while also evolving qmail to meet more present-day needs?

One fork per community

My subtle artwork
notqmail logo == qmail logo overlaid by a red circle with a slash through it

Say hello to notqmail.

Our first release is informed, conservative, and careful — but bold. It reflects our brand-new team’s rapid convergence on where we’re going and how we’ll get there. In the span of a few weeks, we’ve:

  • Started this project
  • Grown to four active developers with diverse concerns, opinions, and skills
  • Defined our big-picture goals (and non-goals)
  • Identified milestones for future releases
  • Agreed on standards for pull requests
  • Merged only the changes that absolutely had to be in the first release
  • Shipped our first release

I say “bold” because, for all the ways we intend to hew to qmail tradition, one of our explicit goals is a significant departure. Back in the day, qmail’s lack of license, redistribution restrictions, technical barriers, and social norms made it hard for OS integrators to create packages, and hard for package users to get help. netqmail 1.06 expressed a desire to change this. In notqmail 1.07, we’ve made packaging much easier. (I’ve already updated pkgsrc from netqmail to notqmail, and some of my colleagues have prepared notqmail RPM and .deb packages.) Further improvements for packagers are part of what’s slated for 1.08.

What’s next

Looking much further ahead, another of our explicit goals is “Meeting all common needs with OS-provided packages”. We have a long way to go. But we couldn’t be off to a better start.

By our design, we believe we’ve made it safe for everyone running qmail to follow notqmail. We hope you’ll vet our changes carefully, then update your installations to notqmail 1.07. We hope you’ll start observing us as we continue the work. We hope you’ll discuss freely on the qmail mailing list. We hope you’ll be a part of the qmail revival in ways that are comfortable for you. And we hope that, in the course of time, notqmail will prove to be the community-driven open-source successor to qmail.

Posted Tue Aug 20 11:13:00 2019 Tags:

On Thursday, May 16, NYC Large Scale Scrum hosted a meetup with LeSS co-creator Craig Larman. The event was held at Morgan Stanley — where I learned Extreme Programming and got my first taste of software development coaching — so it was a pleasure to be back in a speaking capacity. I served as Craig’s opening act, keeping folks warmed up and tuned in with a mix of presentation and discussion until he arrived.

The discussion portion was stoked by Agile in 3 Minutes, specifically Effect and Wrong. One of my favorite things to hear about the podcast is when it helps conversations get going, so one of my favorite things about sharing the material in person is watching that happen. I can still hear the roar of 450 people talking first thing in the morning as I opened AgileIndy 2016.

Photo by Gene Gendel

The presentation portion was me telling stories of growing my Morgan Stanley team’s circles of trust, collaboration, feedback, and impact by improving our technical capabilities in our code. By a show of hands in the room, about half the audience had worked for Morgan Stanley or still does, and least half of those were familiar with the system I had been responsible for. I didn’t know how much time I’d have, so I ordered the stories chronologically and worked my way through two of them — just enough to establish Test-Driven Development as a keystone of our team’s development, and tee up technical excellence as a keystone of the LeSS framework. (To find out how our development continued, read the stories.)

When I handed off the show to Craig, he took a seat up front between the two flipcharts, fielded questions, and held the room for an hour and a half with his expertise and manner. It was my first time hearing him speak, and memorable from the outset. He said things that are often hard to hear in a way that I’m guessing may have been relatively easy for this audience to hear. It was occasion to reflect on how my consulting skills have grown since my time at Morgan Stanley and how I might grow them further. And then it was occasion to go out for tacos with John, with whom I’d spent many a Friday night delivering new code to production. Looking forward to seeing more of my former colleagues soon.

Posted Fri May 17 10:55:31 2019 Tags:

On Friday, May 10, I attended Big Apple Scrum Day, was part of its Coaches Clinic, and co-facilitated a session called Two Midwesterners Politely Invite You To Explore Coding with Faye Thompson.

Faye debriefing after some code

Here’s the abstract:

Wonder what it’s like to do what programmers do? Maybe people have tried to explain it, but didn’t put it in terms that computed for you. Perhaps you’ve considered participating in your team’s mobbing sessions but weren’t confident that you could contribute. Or maybe you would like to become more technical, but the mere thought of trying to code has felt intimidating. Today is a new day!

Faye’s a non-programmer from Ohio, Amitai’s a sometimes-programmer from Illinois, and with your help, we’ll solve a problem by thinking and coding together. If you want to, you can take a brief turn at the keyboard; if not, no biggie. When we’re done, we think you’ll have a new kind of feeling about code and coding. You might even want to pursue it further.

We got the audience we were hoping for: mostly folks who haven’t touched code much before, if at all. Feedback suggests it might make a difference for at least a few of them. For my part, co-presenting with Faye was easy and enjoyable, and her involvement made the session much more effective.

Gitte Klitgaard’s keynote set a powerful tone for my third consecutive Big Apple Scrum Day. It’s always a privilege to present — and to provide free 1-on-1 sessions as part of Gene Gendel’s Coaching Clinic. As an independent consultant, I especially appreciate the chance to offer something of value to an audience that’s local to me.

Posted Fri May 10 18:16:59 2019 Tags: