At Codurance, remote work is already part of who we are. The pandemic, as in many other companies, presented challenges and opportunities, which led us to rethink our work method. It was then when remote work made sense and, although we were already using it in our dynamics with clients, it was consolidated as an organizational reality that allows us, among its many benefits, to attract talent beyond geographical boundaries.
For our team it also meant a learning and adaptation process. So, after a good period of time working in this way, with its benefits and challenges, we wanted to offer a circuit in which, through our experience, we shed light on some of the most common practices of Extreme Programming and the challenges of implementing them remotely.These sessions were led by Javier Chacana, Javier Martínez and Matheus Marabesi, Software Craftspersons at Codurance Spain.
Pair Programming is a practice that, as its name suggests, consists of programming by pairs. It is a procedure of constant mutual collaboration that promotes learning and a more agile development by having immediate feedback. The fear or doubts that can be generated about the positive value of this methodology usually revolve around the lack of knowledge about its true benefits. For this reason, we expose some of its advantages.
Positive aspects of pairing:
- Allows for immediate clarification of ideas
- Mutual support for keeping the focus on the task at hand
- Take the initiative and continue with the development when one of the two is blocked
- Constant feedback
- Sharing responsibility
In Pair Programming, developers share two roles: navigator and driver. They rotate between them, which allows for a more fluid dynamic. The driver is in charge of generating the code while the navigator reviews the work being generated to polish possible errors and make strategic considerations on the design.
Challenges of remote pairing and their possible solution
Working remotely tends to make it easier to lose focus and get distracted for various reasons, whether it's notifications coming through the screen or the inadvertent situations of being at home.
Be aware of these demands and deviations, know that they can happen and take preventive actions such as muting notifications during the session, closing unnecessary tabs and being in a quiet place. Communication, as in many other occasions, is the key. There are days when you are more concentrated and others when it is more difficult, that's why it is a two-way relationship, you have to express it and look for that support in your partner.
In face-to-face the dynamic of the change of roles between the driver and the navigator is clearer and more visual since they are seated side by side and work with a single keyboard. In remote, this presents a new challenge since each one has his own keyboard. To overcome this, one of the fundamental tips is to establish rotation times.
- Chess clock - agree on a set time for role reversal
- Ping pong - A writes a test, B reviews it, then B writes the test and A reviews it, and so on
- Pomodoro - mark a time when roles are kept, then take a short break and switch roles. After 4 pomodoros take a slightly longer break
For remote pairing, it is important to choose a set up and communication platforms that suit the tastes and comfort of the people involved. Also, having the necessary equipment, such as a good microphone, helps to eliminate the extra effort of trying to understand through the screen. Because of the cognitive load, it is sometimes advisable to remove the camera to relieve the pressure of the mirror effect.
We recommend not looking for a very strict structure for pairing. It should have a form, yes, and there should be purpose and good communication, but there should also be room for individuality to find the best way to adapt it to personal tastes.
The remote adds a point of difficulty for various reasons, such as screen fatigue syndrome, lack of physical closeness, etc. Therefore, it is essential to generate agreements from the beginning so that there is a comfortable base from which to start and compensate for these disadvantages.
Test Driven Development
Test Driven Development is a software development practice that consists of stating a hypothesis and then corroborating that hypothesis with the code we are writing, which is the minimum possible.
The 3 laws of TDD
- You cannot write production code unless it is to make a test fail.
- You cannot write more than a single unit test, with enough code to make it fail (compile error is failure).
- You can only write enough production code to make the single failed test pass.
Benefits of TDD
- It tries to decrease the feedback loop of what is being done
- Increases confidence in the code
- Generates coverage against regression (safety net)
- Helps develop in a more structured way to achieve production code that we can use with confidence
- Leads to good design, as long as you know what good design looks like. Maybe it will help you to have a testable code but it will not automatically lead to a well-designed code
- Side effect: it technically raises the level of the team and improves talent retention
Ways to implement TDD in a team
If you practice TDD alone, you are only going to have feedback from your tests, so you don't know if what you are generating looks good or if you are just fulfilling your hypothesis. You need feedback from someone else to get the most out of it. Also, with Pair Programming you can break the impostorsyndrome and learn more from each other.
Pair Programming styles or scenarios that may occur depending on the knowledge of the driver and navigator:
TDD in remote: recommendations
In remote, one of the biggest challenges is distraction, we are more prepared to work physically, but we must try to be engaged. There is an important cognitive load and that is why rotation is key, because having control of the keyboard helps to maintain focus. The idea is not that the structure is perfect, but to support each other to maintain concentration.
Establish a rotation policy in advance
- Unstructured (ad hoc). Depending on experience and time spent together it may come naturally. When the other experiences a blockage the other comes in to help and they change according to the need or preference between them.
- Timer. Set a specific time
- Ping pong. Ping pong rules for tdd say that rotation occurs on red.
Establish the method by which control of the code will be exercised.
- Only remote control of a computer
- Plugins or tools like Code with me
Coding Standards, Collective Ownership y Refactoring
Coding standards are general guidelines or agreements within the team that facilitate the task of development and unified code control. This list of rules, also known as code conventions, allows the resulting code to look uniform no matter who wrote it.
Among its benefits, unifying code helps remove the cognitive burden of reading code. If there is a unified base, any developer reading that code will feel more familiar and will be able to work more freely. We believe that, all the more so in remote environments, it is necessary to maintain code standards.
Reasons to implement Coding standards:
- Improve code reading
- Minimize maintenance costs
- Increase development speed
Today we have some tools that allow us to formalize and force the adoption of these standards.
Some ways of documenting and automating conventions
- Use of linters and prettiers
- EditorConfig. A very good tool for multidisciplinary and multiplatform teams working with any text editor, it simply makes a standardization through a file where the agreements are declared
- Githooks to force verifications
- Fix dependency and runtime versions
- Use static code analyzers
Collective Code Ownership: Does everyone do everything?
- No, but everyone is responsible for the entire code
- It is an organizational policy and at the same time a sentiment
- Pair programming with rotation helps to improve ownership
- Improves knowledge distribution
- Improves quality and reduces rework
- It is not a question of everyone doing everything, but of everyone being able to do everything.
Ownership can be related to QA, not as a stage but as something holistic and part of that responsibility itself. All these practices help to integrate quality from the beginning.
Remote Pull Request?
At Codurance we prefer Trunk Base Development over Pull Request, although in highly regulated environments or teams that live in very different time zones, Pull Request allows an important level of asynchrony. In this aspect a benefit of remote is the possibility of asynchrony.
Refactoring and technical debt
Refactoring is one of the original core practices of XP and consists of improving the internal structure of a program's source code while preserving its external behavior. Refactoring is something that should happen constantly, it is not rewriting code or fixing bugs.
If you are refactoring it means that you are somehow paying technical debt. Technical debt can be, for example, due to lack of knowledge by not knowing how to solve a problem, or at the design level by trying to improve your time to market. There is also code debt, acquired by bad habits. This debt can be generated consciously or unconsciously and is "paid" by refactoring.
To deal with it, follow up to identify it and constantly refactor. Remotely, it can help to have sessions where this debt is exposed and determine quality gates (actions, code conventions and tests) that help to pay it off.
Join our community
If you want to keep up to date with everything we do: events, podcasts, blogposts, success stories, workshops, katas, etc. Subscribe to our newsletter and we will send you content to inspire you. Also, we invite you to check our events page where we upload all our sessions and workshops.