Pair programming in the software industry has varying acceptance. The answer to whether developers should do more pair programming is normally opinion based. The recent experience I had with my colleague Simon produced some promising results. We had a few productive pair sessions in two weeks developing a payments feature in our Claims product. After the first session we could certainly feel the benefits so decided to do some more. The COVID-19 pandemic sounds like it would impact the pair-programming as it is not possible for the two developers to sit at one machine. But there is nothing to stop remote pairings. It could turn out to be the other way around for some people by improving social connections.
Broadly speaking, we started with some sort of “pair development” mindset as the development of a user story requires not only coding, but many other tasks. We analysed the data model changes, discussed the system behaviour related to each new object/field, drew UML diagrams, mocked up UI prototypes, and drafted documentations in the first couple of sessions. What we were doing there was to clarify ideas, discuss approaches, and come up with a concrete design both of us would feel comfortable to start the coding with.
Before each session, we agreed on how long this session was going to take and what problems we should focus on solving. When there was remaining time, we just went on to solve the next issue. Here are the tools we used:
- VS Code and its SFDX plugins – the IDE
- Live Share – a plugging in VS Code to share code (stopped using because it auto launches a diff view)
- Slack for screen sharing
We mostly used the “Driver and Navigator” style. The Driver is the person who typed the code at the keyboard. The Navigator is in the observer who gives directions, shares thoughts, keeps an eye on the larger issues while the driver is typing. A unique benefit of remote pairings is that the navigator also has a machine and a keyboard so can go find quick answers to driver’s questions. How many times do we, as an individual programmer, have to pause the typing and go find the answer to a specific coding issue or search the code base to find what a class/method is doing? With such a remote pair, the driver can continue the driving smoothly leaving the blocking questions to the navigator and come back to solve them asynchronously.
Pair programming requires intensive focus.
The advantage of pair programming is its gripping immediacy: it is impossible to ignore the reviewer when he or she is sitting right next to you.
— Jeff Atwood
One direct benefit of focus is that code turned out to be simpler and algorithms are implemented faster. Simon and I are both familiar with the payments module code base. We needed to implement an algorithm that does some complex date range partitioning logic. In this situation, we tried to follow the “driver and navigator” style for a while, but we were still stuck. As we discussed ideas, we found two different strategies of traversing a tree data structure (top-down or bottom-up) using a recursive method invocation. We spent 15 minutes writing pseudo-code independently. Each of us handled one strategy and then we regrouped to discuss both. In the end, surprisingly we even simplified the implementation by removing the need of the recursive process and the algorithm looked much simpler. It took us 2 hours. But it could have easily taken me the whole day if I worked independently as I imagined it.
Another benefit of the intensive focus is removing errors effectively on the go. The errors range from the compilation errors to the typical copy and paste errors, all the way through the business level edge case problems. In another session where I was the driver, after a two hour non-stop coding session, I successfully pushed all the code changes into the Salesforce server from my VS code IDE in one go, without a single compilation error. This saved time as saving code to server is a non-trivial time consuming factor when coding on the Salesforce platform.
Apart from many known benefits of pair programming such as knowledge sharing, keeping focus, code review on-the-go, etc., I believe teams should encourage more practices of pair development in the Salesforce platform considering some of the platform specific challenges like:
- More declarative approaches (process builder, formulas, flow, etc.) to solve the problem directly or simplify some of the coding tasks.
- Various limits and considerations – not just governor limits, but also restrictions and considerations (like the choose between Master-detail and Lookup, the choose between the before and the after triggers, execution order, etc.).
- Bulkification, although almost embedded into every Salesforce developer’s blood, is sometimes still dismissed or mistakenly used, even by an experienced developer.
- Platform specific security issues.
- Configurations / Administrations. Things like profile permissions, layout changes, field-level securities, custom settings, etc. if get missed in a configuration or deployment, can cause the effect that nothing feels to be developed.
In a retrospective session, Simon and I reviewed the approach and its costs and benefits. The conclusion is that pair development is vital for collaborative teamwork, it produces high quality deliverables, and it is effective when tackling a large user story.
Melbourne, Australia.
Force 746 