Pair Programming With Salesforce App Cloud

I  am one of two remote developers on the Nimble AMS engineering team and since September have been pair programing with another developer (Bob) who works in at NimbleUser headquarters in Rochester, New York.  ​

​Wikipedia defines pair programming as an agile software development technique in which two programmers work as a pair together on one workstation. For NimbleUser’s first foray into pair programming we went with a Ping/Pong approach where one user works on a task while the other tests it, then they reverse roles for the next task.

Enhanced Communication.

Our exchanges on technical aspects of tickets and implementation approaches has increased on the our Squad as a result of this work.

Nimble AMS (Association Management Software) consists of a backend system that is used by an association’s staff and a front-end portal site that is used by the association’s members/constituents.  With pair programming we get the frontend work and backend work done in a single subtask, instead of dividing it into two sub tasks.  We depend on each other to complete a story.

Better Testing.

Having the person writing the tests isolated from the actual implementation code has allowed us to more effectively handle edge cases and build more thorough unit tests.

Redundancy.

Tickets are seldom halted by a sick day or a vacation. If one of us is out the remaining programmer is familiar enough with the task to continue the work.

Less Mistakes.

We are constantly reviewing each other’s work so mistakes don’t slip through nearly as often.

Increased Velocity.

Having the powers of a predominantly frontend oriented developer paired with a predominantly backend oriented developer has allowed us to ship stories more rapidly.

Less Silos.

Our skill-sets have become more well rounded overall since we are cross-training each other on areas of development they are historically less focused on, leading to less silos.

Less downtime.

Roadblocks are less likely when you have an extra pair of eyes on the problem at all times. Less time spent spinning wheels waiting for another engineer to free up and more time talking through the problem together.

I Feel More Connected.

Pair programming connects me  to the office in a very real way, bridging the gap between being remote and local.

Since Bob and I are 230 miles apart, sitting at the same computer and keyboard is not feasible. Additionally, working on separate computers can be tricky when it comes to working on the same files and components.

• Open Hailing Frequencies.  We each use our own computer and utilize a full time Google Hangout to share primary displays at all times.  This allows for constant collaboration with screen sharing and audio.  We can see each other’s code, and rapidly assist without the need for a massive focus shift.
• Separation of Concerns:
  • We cannot both work in the same exact file at the same exact time.  Nimble AMS is built on the Salesforce App Cloud platform.  This would create code conflicts, and trickiness in the multi-tenant Salesforce environment.
  • One person writes the implementation code, the other writes unit tests against that code. These roles alternate between tickets depending on an agreed-upon division of work.
  • We share a single Git branch and a single Salesforce development org.
• Paired Code Review.  NimbleUser has a two step code review process.  The first review (CR1) is done by any member of the team and the second review (CR2) is done by a developer who is a subject matter expert in the module.  Bob and I perform CR1 together and make updates as needed before having another team member perform CR2.

“Craig has much more experience with Nimble AMS than I do, so pairing with him has been the most valuable learning experience of my tenure here!  Instead of reading documents or attending training sessions I’m in the thick of it with an expert getting things done.”
-Bob Lawton, NimbleUser Software Engineer

• Constant communication is a must.  In order to prevent duplicate work and confusion both members of the pair need to vocalize the decisions they are making in real-time. If both engineers start working in the same file or on the same feature duplicate work and churn are inevitable!
• Complimentary skill sets are needed to be most thorough and effective. Two folks who specialize in the same area of expertise may not see as much of an improvement as two with complimentary skill sets.
• Branch maintenance is a must. If we get out of sync it will create churn at best and loss of work at worst.
• Sometimes there’s just not enough work in a single ticket for two people e.g. easy bug tickets. In situations like this, typically one developer will do the work, the other will write up a manual test plan while likely addressing a separate ticket.
• Don’t expect an increased velocity right off the bat.  Ramp up time is inevitable when you put two engineers used to working solo together.

A study of pair programming by University of Utah Computer Science department determined that pair programming increases cost by approximately 15% but this is repaid in shorter and less expensive testing, quality assurance, and field support.
​
As with anything new, there are challenges but pair programming has yielded tangible benefits to NimbleUser and we are looking for ways to do more of it. Let us know how pair programming works out for you in the comments section.